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Description 

[0001] The present invention relates to a generic IVIPEG table processor for processing a transport pacl<et stream. 
Tine invention is particular suitable for a receiver/decoder for a digital transnnission system, in particular for use in a 

5 digital television system. 

[0002] As used herein, the term "digital television system" includes for example any satellite, terrestrial, cable and 
other system. 

[0003] The term "receiver/decoder" as used herein may connote a receiver for receiving either encoded or non- 
encoded signals, for example television and/or radio signals, which may be broadcast or transmitted by some other 
10 means. The term may also connote a decoder for decoding received signals. Embodiments of such receiver/decoders 
may include a decoder integral with the receiver for decoding the received signals, for example, in a "set-top box", 
such as a decoder functioning in combination with a physically separate receiver, or such a decoder including additional 
functions, such as a web browser, a video recorder, or a television. 

[0004] The term MPEG refers to the data transmission standards developed by the International Standards Organ- 
15 isation working group "Motion Pictures Expert Group" and in particular but not exclusively the MPEG-2 standard de- 
veloped for digital television applications and set out in the documents ISO 13818-1, ISO 13818-2, ISO 13818-3 and 
ISO 1 3818-4. In the context of the present patent application, the term includes all variants, modifications or develop- 
ments of MPEG formats applicable to the field of digital data transmission. 

[0005] According to a first aspect of the present invention, there is provided a data structure for an MPEG private 
20 table section including a data portion, the data structure comprising a size specifier specifying a measure of the size 
of the section or the data portion, the data portion comprising at least one data blocl<, the or each block including a 
further size specifier specifying a measure of the size of that block. 

[0006] By having a further size specifier in addition to the specifier conventionally provided in the table section, that 

further size specifier specifying a measure of the size of a particular data block, the need to provide a different structure 
25 for each use of the MPEG private table section can be eliminated, since a generic data structure can be defined. 

Furthermore, the table section can be backwards compatible, since the conventional size specifier can be retained. 

[0007] It will be understood that the MPEG standard size specifier as referred to above specifies the size of the 

section in terms of the number of remaining bytes in the section after the size specifier. However, other measures of 

the size of the section or the data portion fall within the ambit of this invention. 
30 [0008] In particular, in orderto achieve more complex data structures, the data portion preferably comprises a plurality 

of data blocks, each including a respective one of such further size specifiers. 

[0009] According to a further aspect of the invention, there is provided a data structure for an MPEG private table 
section including a data portion, the data portion comprising a plurality of data blocks, each block including a size 
specifier specifying a measure of the size of its respective block. 
35 [0010] The structure preferably further comprises a list of blocks. 

[0011] This can allow a yet more complex data structure. A list may contain no blocks, one block or a plurality (or 
indeed multiplicity) of blocks. 

[001 2] Preferably, such a list includes a list specifier specifying a measure of the overall size of the blocks in the list. 
This can allow the data structure to remain parsable. The list specifier may for example specify the number of relevant 
40 blocks or their entire length. 

[001 3] For yet further complex data structures, the structure preferably comprises a plurality of such lists. 

[0014] The structure preferably further comprises at least one block having data common to such plurality of lists. 

This can improve the versatility of the data structure. 

[0015] For the same reason, the or each block in such list has data specific to its particular list. 
45 [0016] It will of course be understood that in this context, reference to a list includes reference to what that list 
represents. 

[0017] The structure preferably comprises a plurality of blocks in such a list. 

[0018] In orderto afford more functionality to the data structure, the structure preferably further comprises an identifier 
representative of the content of a respective list. 
50 [0019] For ease of parsing the data structure, the size specifier is located in a header portion of the block. 
[0020] Preferably, at least one such block includes a tag representative of its content. 

[0021] Hence, the block with the required data can be retrieved or filtered. Depending upon requirement, the tag 
may contain any information relevant to the content of the block. 

[0022] A preferred embodiment of data structure for an MPEG privatetable comprises only one structure as described 
55 above. 

[0023] An alternative embodiment of data structure for an MPEG private table comprises a plurality of structures as 
described above. 

[0024] Hence two generic data structures can be defined, each of which can have a single overall structure. These 
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two generic structures can be used dependent upon circumstances. 

[0025] The structure preferably includes an MPEG standard header and a further header. 

[0026] Preferably the further header includes a flag representative of the state of transformation of the data. For 
instance the flag may be representative of a state of compression or encryption of the data. 
5 [0027] Alternatively, or in addition, the further header may include a flag representative of a type of transformation 
which has been applied to the data portion. 

[0028] A further aspect of the invention provides a method of assembling an M PEG private table, comprising providing 
a data portion and adding a flag representative of a state or type of transformation of the data portion. 
[0029] The flags described above can then be used in a subsequent processor (such as a receiver/decoder) to 
10 determine the state or type of transformation. For instance the flag may be used to distinguish between compressed 
and uncompressed tables, or to distinguish between encrypted and unencrypted tables. The use of flags also allows 
several different transformation algorithms to be in use. This creates greater flexibility, for instance enabling different 
algorithms to be used on different kinds of data. 

[0030] Preferably the data portion has been subject to a transformation, such as compression or encryption. Pref- 
^5 erably the standard header and further header are uncompressed and not encrypted. This ensures compatibility with 
existing system hardware and software. 

[0031 ] Preferably the further header includes a filter specifier and/or a field for specifying a parser type and/or a field 
for specifying the priority with which the private table section is to be processed. Typically the parser type field is the 
first field of the further header. 

20 [0032] According to a further aspect of the invention, there is provided a data structure for an MPEG private table 
section, comprising an MPEG standard header, a further header and a data portion. 

[0033] The presence of the MPEG standard header can permit compatibility with existing private table sections, 
whilst the presence of the further header can allow the incorporation of additional functionality into the table section. 
[0034] The further header preferably includes a flag representative of the state or type of transformation applied to 
25 the data portion. 

[0035] The further header preferably includes a flag representative of the state of compression of the data. Hence, 
less bandwidth may be required. Preferably the standard header and further header are not in a compressed form. 
[0036] The further header may also include a flag representative of the state of encryption of the data. The private 
table section may therefore only be read by those with the encryption code. Preferably the standard header and further 
30 header are not in an encrypted form. 

[0037] The further header preferably also includes a filter specifier. Hence, enhanced functionality can be afforded 
to the filtering of the data. 

[0038] The further header preferably comprises a field for specifying a parser type. This can afford greater versatility. 
[0039] For ease of parsing, the parser type field is the first field of the further header. 
35 [0040] Again for additional functionality, the further header comprises a field for specifying the priority with which the 
private table section is to be processed. For example, if several tables of the same kind are received at the same time, 
the priority field may be used to determine the order in which they are processed. 

[0041] A further aspect of the invention provides a method of performing a transformation on an MPEG private table, 
the table comprising a data portion, the method comprising compressing the data portion so as to form a transformed 

40 data portion. 

[0042] A further aspect of the invention provides a method of performing a transformation on an MPEG private table, 
the table comprising a data portion, the method comprising decompressing the data portion so as to form a transformed 
data portion. 

[0043] A further aspect of the invention provides a method of performing a transformation on an MPEG private table, 
45 the table comprising a data portion, the method comprising encrypting the data portion so as to form a transformed 
data portion. 

[0044] A further aspect of the invention provides a method of performing a transformation on an MPEG private table, 
the table comprising a data portion, the method comprising decrypting the data portion so as to form a transformed 
data portion. 

50 [0045] The method preferably further comprises adding a flag representative of the state or type of transformation 
perfomried on the transformed data portion. 

[0046] A further aspect of the invention provides a method of performing a transformation on a plurality of data blocks, 
comprising assembling the data blocks to form an intermediate block and performing a transformation on the interme- 
diate block, so as to form a transformed block. 
55 [0047] Instead of individually and separately transforming each data block, according to this aspect of the invention, 
the data blocks are processed in bulk in the fonn of an intemnediate block. This can reduce processing overheads. 
Examples of typical transformation processes include compression, decompression, encryption and decryption. 
[0048] Preferably the transformation comprises splitting a block into a plurality of sub-blocks, and optionally adding 



3 



EP 1 267 579 A2 



a flag representative of the state and/or type of transformation of tine data to each sub-block. 
[0049] The transformed block may be transmitted to a recipient, and/or received from a transmitter. 
[0050] Typically the method further comprises performing a further transformation on the transformed block: typically 
the inverse of said transformation. 
5 [0051] Performing the further transformation typically comprises assembling the sub-blocks so as to form a further 
intermediate block, and performing the further transformation on the further intermediate block. 
[0052] A standard header may be added to each sub-block. 

[0053] Typically the assembling step comprises including in the intermediate block size specifiers each specifying 
the size of a respective data block. This enables the data blocks to be extracted from the intennedlate block in a 
10 subsequent processing step. Each specifier may precede its respective data block, or may be associated with its 
respective data block in some other way. 

[0054] Alternatively a size specifier in the transformed block may be inspected to determine how the block should 

be split into sub-blocks. This enables a previous data block structure to be recreated. 
[0055] Typically said plurality of data blocks are data portions of an MPEG private table. 
15 [0056] The transformed block is typically also used to form part of a transformed MPEG private table. 

[0057] Typically the MPEG private table comprises a plurality of table sections each including a standard header and 
a data portion, and the transformed MPEG privatetable comprises a plurality of table sections each including a standard 
header and a transformed data portion provided by the transformed block. 

[0058] At least a part of a header in the transformed MPEG private table may be substantially identical to a part of 
20 a standard header in the MPEG private table. 

[0059] The method may further comprise including a value in the transformed MPEG private table specifying the 
type and/or state of transformation. 

[0060] The method preferably comprises the step of adding target information which identifies a receiver/decoder 

or group of receiver/decoders which is an intended recipient of the data. 
25 [0061] The target information may directly identify a specific receiver/decoder or group or receiver/decoders, for 

Instance by listing the smartcard number(s) of the identified receiver/decoders. Alternatively the target information may 

identify the receiver/decoder(s) in some indirect way, for instance by identifying a software or hardware platform. 

[0062] A further aspect of the invention provides a data structure comprising a plurality of compressed data blocks, 

wherein the compressed data blocks can be decompressed to provide a plurality of decompressed data blocks, each 
30 decompressed data block including a data portion and a size specifier specifying the size of the data portion. 

[0063] Typically the number of decompressed data blocks is greater than the number of compressed data blocks. 

This reduces processing overheads. 

[0064] Typically the data structure further comprises a header associated with each compressed data block. 
[0065] A further aspect of the invention provides a data structure comprising a plurality of encrypted data blocks, 
35 wherein the encrypted data blocks can be decrypted to provide a plurality of decrypted data blocks, each decrypted 
data block including a data portion and a size specifier specifying the size of the data portion, 
[0066] Typically the data structure further comprises a header associated with each decrypted data block. 
[0067] Typically the header is a standard MPEG header 

[0068] A further aspect of the invention provides a compressed MPEG private table section and/or a compressed 
40 MPEG private table. Compression of the standard MPEG private tables saves storage space and bandwidth. 

[0069] A further aspect of the invention provides an encrypted MPEG private table section and/or an encrypted 
MPEG private table. 

[0070] A further aspect of the invention provides an MPEG private table section or MPEG private table comprising 
target information which identifies a receiver/decoder or group of receiver/decoders which is an intended recipient of 

45 the MPEG private table section. 

[0071] The target information may directly identify a specific receiver/decoder or group or receiver/decoders, for 
instance by listing the smartcard number(s) of the identified receiver/decoders. Alternatively the target information may 
identify the receive r/decoder(s) in some indirect way, for instance by identifying a software or hardware platform. 
[0072] A further aspect of the invention provides a method of assembling an MPEG privatetable section, the method 

50 comprising inserting target information which identifies a receiver/decoder or group of receiver/decoders which is an 
intended recipient of the MPEG private table section. 

[0073] A further aspect of the invention provides apparatus for assembling an M PEG private table, comprising means 
for providing a transformed data portion which has been subject to a transformation and means for adding a flag 
representative of the type of transformation. 
55 [0074] A further aspect of the invention provides apparatus for peri'orming a transformation on an MPEG private 
table, the table comprising a data portion, the apparatus comprising means for compressing, decompressing, encrypt- 
ing and/or decrypting the data portion so as to form a transformed data portion. 

[0075] A further aspect of the invention provides apparatus for performing a transformation on a plurality of data 
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blocks, comprising means for assembling the data blocks to form an intermediate block and means for performing a 
transformation on the intermediate block, so as to form a transformed block. 

[0076] A further aspect of the invention provides apparatus for assembling an MPEG private table section, the ap- 
paratus comprising means for inserting target information which identifies a receiver/decoder or group of receiver/ 

5 decoders which is an intended recipient of the MPEG private table section. 

[0077] According to a further aspect of the invention, there is provided a parser for parsing an MPEG private table 
section including a data portion, comprising means (for example in the form of a processor with associated memory) 
for parsing data in a format comprising a size specifier specifying a measure of the size of the section or the data 
portion, the data portion comprising at least one data block, the or each block including a further size specifier specifying 

10 a measure of the size of that block. 

[0078] Preferably, the parser is adapted to parse data in a format wherein the data portion comprises a plurality of 
data blocks, each including a respective one of such further size specifiers. 

[0079] Preferably, the parser is adapted to parse data in a format further comprising a list of blocks, 
[0080] Preferably, the parser is adapted to parse data in a format wherein such list includes a list specifier specifying 
15 a measure of the overall size of the blocks in the list. 

[0081] Preferably, the parser is adapted to parse data in a format comprising a plurality of such lists. 

[0082] Preferably, the parser is adapted to parse data in a format further comprising at least one block having data 

common to such plurality of lists, 

[0083] Preferably, the parser is adapted to parse data in a format wherein the or each block in such list has data 
20 specific to its particular list. 

[0084] Preferably, the parser is adapted to parse data in such a way that such specific data overrides such common 
data. 

[0085] Preferably, the parser is adapted to parse data in a format comprising a plurality of blocks in such list. 
[0086] Preferably, the parser is adapted to parse data in a format further comprising an identifier representative of 
25 the content of a respective list. 

[0087] Preferably, the parser is adapted to parse data in a format wherein the size specifier is located in a header 
portion of the block. 

[0088] Preferably, the parser is adapted to parse data in a format wherein at least one such block includes a tag 
representative of its content. 
30 [0089] Preferably, the parser is adapted to parse data in a fomriat comprising only one MPEG section. 

[0090] Alternatively, the parser is adapted to parse data in a format comprising a plurality of MPEG sections. 
[0091] Preferably, the parser is adapted to parse data in a format including an MPEG standard header and a further 
header. 

[0092] According to a further aspect of the invention, there is provided a parser for parsing an MPEG private table 
35 section, comprising means (for example in the form of a processor with associated memory) for parsing data in a format 
comprising an MPEG standard header, a further header and a data portion, 

[0093] Preferably, the parser is adapted to parse data in a format wherein the further header includes a flag repre- 
sentative of the state of compression of the data. 

[0094] Preferably, the parser is adapted to parse data in a format wherein the further header includes a flag repre- 
40 sentative of the state of encryption of the data. 

[0095] Preferably, the parser is adapted to parse data in a format wherein the further header includes a filter specifier, 
[0096] Preferably, the parser is adapted to parse data in a format wherein the further header comprises a field for 
specifying a parser type. 

[0097] Preferably, the parser is adapted to parse data in a format wherein the parser type field is the first field of the 
45 further header. 

[0098] Preferably, the parser is adapted to parse data in a format wherein the further header comprises a field for 

specifying the priority with which the private table section is to be processed, 

[0099] According to a further aspect of the invention, there is provided a parser for parsing an MPEG private table 
section comprising an MPEG standard header and a data portion, the MPEG standard header including a TID extension 
50 field, comprising means (for example in the form of a processor with associated memory) for outputting the value of 
the TID extension field. Previously, the TID extension field had been ignored. 

[0100] There is preferably provided a receiver / decoder including a parser as described above. The present invention 
is not, however, limited to a receiver/decoder, but can be implemented in PCs, for example. 

[0101] The data may be transmitted in a broadcast stream. The data can then be extracted at the receiver end from 
55 the broadcast stream. 

[0102] In a preferred embodiment the method is employed in a system including a digital broadcast centre, and a 
plurality of receiver/decoders. 

[0103] The data can then be employed in a variety of tasks. For instance it may contain action notification data for 
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controlling a function of the receiver/decoder. Alternatively the data may contain programme information for use in a 
video-on-demand system. Alternatively the data may contain key data for use by a receiver/decoder to obtain access 
to a conditional access system. 

[0104] The receiver/decoder preferably includes means (for example in the form of a processor with associated 

5 memory) for receiving the value of the TID extension field and for processing such value. 

[0105] The receiving and processing means is preferably adapted to process such value as a notification to a user 
of the receiver/decoder. 

[01 06] The receiving and processing means is preferably adapted to process such value as data concerning content 
received by the receiver/decoder. 
10 [01 07] There is preferably provided a receiver/decoder adapted to receive and/or decode data in a data structure as 
described earlier or which has been assembled, processed or transformed as described earlier. 
[01 08] A transmitter adapted to transmit data in a data structure as described earlier, or which has been assembled, 
processed or transformed as described earlier. 

[01 09] There is further provided a broadcasting system incorporating a receiver/decoder and a transmitter described 
15 above. 

[01 1 0] The data in the broadcasting system is preferably conditional access data, the system being adapted to trans- 
mit and receive such data on a separate channel. 

[0111] There is also provided a method of processing data comprising converting such data between a given format 
and data in the format of a data structure as described earlier. The given format may be any format into which or out 
20 of which it may be desired to convert data from the format of the data structure as aforesaid. 

[0112] The invention also provides a method substantially as described herein with reference to the accompanying 
drawings, and apparatus substantially as described herein with reference to and as illustrated in the accompanying 
drawings. 

[0113] The invention extends to a computer program product adapted to perform a method as aforesaid. 

25 [01 14] The invention further extends to a computer readable medium embodying a parser as described above. 
[01 1 5] The invention yet further extends to a signal tangibly embodying a parser as described above. 
[01 16] The invention also provides a computer program and a computer program product for carrying out any of the 
methods described herein and/or for embodying any of the apparatus features described herein, and a computer read- 
able medium having stored thereon a program for carrying out any of the methods described herein and/or for embod- 

30 ying any of the apparatus features described herein. 

[0117] The invention also provides a signal embodying a computer program for carrying out any of the methods 
described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such 
a signal, and a computer product having an operating system which supports a computer program for carrying out any 
of the methods described herein and/or for embodying any of the apparatus features described herein. 

35 [01 1 8] Features implemented in hardware may generally be implemented in software, and vice versa. Any references 
to software and hardware features herein should be construed accordingly. 

[0119] Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate 

combination. In particular method aspects may be applied to apparatus aspects, and vice versa. 

[0120] Preferred features of the present invention will now be described, purely by way of example, with reference 

40 to the accompanying drawings, in which:- 

Figure 1 shows the overall architecture of a digital television system; 

Figure 2 shows the architecture of the conditional access system; 

Figure 3 shows the general form of an EIVIM; 

45 Figure 4 shows a typical configuration of the SAS; 

Figure 5 shows the receiver/decoder in detail; 

Figure 6 shows the five software layers contained by the receiver/decoder; 

Figure 7a illustrates an interrelationship between a number of components of an MPEG stream; 

Figure 7b shows how an application may be made up of modulesAables, which in turn may be made up of sections; 

50 Figure 7c illustrates the content of a directory module; 

Figure 8 shows a data structure according to an embodiment of the invention; 

Figure 9 shows the role of the parser within the set top box; 

Figure 1 0 illustrates the selection of an Action Notification Table; 

Figure 1 1 A illustrates the compression of a private table; and 

55 Figure 1 1 B illustrates the decompression of a compressed private table. 
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System Overview 

[01 21 ] An overview of a digital television system 1 is shown in Figure 1 . The invention includes a mostly conventional 
digital television system 2 that uses the known MPEG-2 compression system to transmit compressed digital signals. 

5 In more detail, MPEG-2 compressors in a broadcast centre receives a digital signal stream (typically a stream of video 
signals). The compressor 3 is connected to a multiplexer and scrambler 4 by linkage 5. 

[0122] The multiplexer 4 receives a plurality of further Input signals, assembles the transport stream and transmits 
compressed digital signals to a transmitter 6 of the broadcast centre via linkage 7, which can of course take a wide 
variety of forms including telecommunications links. The transmitter 6 transmits electromagnetic signals via uplink 8 

10 towards a satellite transponder 9, where they are electronically processed and broadcast via notional downlink 1 0 to 
earth receiver 12, conventionally in the form of a dish owned or rented by the end user. Other transport channels for 
transmission of the data are of course possible, such as terrestrial broadcast, cable transmission, combined satellite/ 
cable links, telephone networks etc. 

[01 23] The signals received by receiver 1 2 are transmitted to an integrated receiver/decoder 1 3 owned or rented by 
15 the end user and connected to the end user's television set 14. The receiver/decoder 13 decodes the compressed 
MPEG-2 signal into a television signal for the television set 14. Although a separate receiver/decoder Is shown in Figure 
1 , the receiver/decoder may also be part of an Integrated digital television. As used herein, thetenn "receiver/decoder" 
includes a separate receiver/decoder, such as a set-top box, and a television having a receiver/decoder integrated 
therewith. 

20 [0124] In a multichannel system, the multiplexer 4 handles audio and video Information received from a number of 
parallel sources and Interacts with the transmitter 6 to broadcast the infomiatlon along a corresponding number of 
channels. In addition to audiovisual Information, messages or applications or any other sort of digital data may be 
introduced in some or all of these channels interlaced with the transmitted digital audio and video information. 
[01 25] A conditional access system 1 5 is connected to the multiplexer 4 and the receiver/decoder 1 3, and is located 

25 partly In the broadcast centre and partly In the receiver/decoder. It enables the end user to access digital television 
broadcasts from one or more broadcast suppliers. A smartcard, capable of deciphering messages relating to commer- 
cial offers (that is, one or several television programmes sold by the broadcast supplier), can be inserted into the 
receiver/decoder 13. Using the receiver/decoder 13 and smartcard, the end user may purchase commercial offers In 
either a subscription mode or a pay-per-view mode. 

30 [01 26] As mentioned above, programmes transmitted by the system are scrambled at the multiplexer 4, the conditions 
and encryption keys applied to a given transmission being determined by the access control system 15. Transmission 
of scrambled data in this way is well known in the field of pay TV systems. Typically, scrambled data is transmitted 
together with a control word for descrambling of the data, the control word Itself being encrypted by a so-called exploi- 
tation key and transmitted in encrypted form. 

35 [01 27] The scrambled data and encrypted control word are then received by the receiver/decoder 1 3 having access 
to an equivalent to the exploitation key stored on a smartcard inserted in the receiver/decoder to decrypt the encrypted 
control word and thereafter descramble the transmitted data. A paid-up subscriber will receive, for example, in a broad- 
cast monthly EMM (Entitlement Management Message) the exploitation key necessary to decrypt the encrypted control 
word so as to permit viewing of the transmission. 

40 [01 28] An interactive system 1 6, also connected to the multiplexer 4 and the receiver/decoder 1 3 and again located 
partly in the broadcast centre and partly in the receiver/decoder, enables the end user to interact with various applica- 
tions via a back channel 17. The back channel may be, for example a Public Switched Telephone Network (PSTN) 
channel (for example, a modemmed back channel) or an Out of Band (OOB) channel. The back channel may also be 
used for communications used In the conditional access system 15. 

45 

Conditional Access System 

[0129] With reference to Figure 2, in overview the conditional access system 15 includes a Subscriber Authorization 
System (SAS) 30. The SAS 30 is connected to one or more Subscriber Management Systems (SMS) 32, one SMS 

50 for each broadcast supplier, by a link 34, which may be a TCP-IP linker other type of link. Alternatively, one SMS could 
be shared between two commercial operators, or one operator could use two SMSs, and so on. 
[0130] First encrypting units in the form of ciphering units 36 utilising "mother" smartcards 38 are connected to the 
SAS by linkage 40. Second encrypting units again in the form of ciphering units 42 utilising mother smartcards 44 are 
connected to the multiplexer 4 by linkage 46. The receiver/decoder 1 3 receives a "daughter" smartcard 48. The receiver/ 

55 decoder is connected directly to the SAS 30 via Communications Servers 50 and the modemmed back channel 1 7. 
The SAS sends amongst other things subscription rights to the daughter smartcard on request. 
[0131] The smartcards contain confidential information from one or more commercial operators. The "mother" smart- 
card encrypts different kinds of messages and the "daughter" smartcards decrypt the messages, if they have the rights 
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to do so. 

[0132] With reference to Figure 2, in the broadcast centre, the digital video signal is first connpressed (or bit rate 
reduced), using the MPEG-2 connpressor 3. This connpressed signal is then transmitted to the multiplexer and scrambler 
4 in order to be multiplexed with other data, such as other compressed data. 
5 [0133] The scrambler generates a control word used in the scrambling process and included in the MPEG-2 stream 
in the multiplexer 4. The control word is generated internally and enables the end user's integrated receiver/decoder 
13 to descramble the programme. 

[0134] Access criteria, indicating how the programme is commercialised, are also added to the MPEG-2 stream. The 
programme may be commercialised in either one of a number of "subscription" modes and/or one of a number of "Pay 

10 Per View" (PPV) modes or events. In the subscription mode, the end user subscribes to one or more commercial offers, 
or "bouquets", thus getting the rights to watch every channel inside those bouquets. In the Pay Per View mode, the 
end user is provided with the capability to purchase events as he wishes. 

[0135] Both the control word and the access criteria are used to build an Entitlement Control Message (ECM); this 
is a message sent in relation with one scrambled program; the message contains a control word (which allows for the 
15 descrambling of the program) and the access criteria of the broadcast program. The access criteria and control word 
are transmitted to the second encrypting unit 42 via the linkage 46. In this unit, an ECM is generated, encrypted and 
transmitted on to the multiplexer and scrambler 4. 

[01 36] Each service broadcast by a broadcast supplier in a data stream comprises a number of distinct components; 
for example a television programme includes a video component, an audio component, a sub-title component and so 
20 on. Each of these components of a service is individually scrambled and encrypted for subsequent broadcast. In respect 
of each scrambled component of the service, a separate ECM is required. 

[0137] The multiplexer 4 receives electrical signals comprising encrypted EMMs from the SAS 30, encrypted ECMs 
from the second encrypting unit 42 and compressed programmes from the compressor 3. The multiplexer 4 scrambles 
the programmes and transmits the scrambled programmes, the encrypted EMMs and the encrypted ECMs as electric 
25 signals to broadcast system 54, which may be for example a satellite system as shown in Figure 1 , or other broadcast 
system. The receiver/decoder 13 demultiplexes the signals to obtain scrambled programmes with encrypted EMMs 
and encrypted ECMs. 

[0138] The receiver/decoder receives the broadcast signal and extracts the MPEG-2 data stream. If a programme 
is scrambled, the receiver/decoder 1 3 extracts the corresponding ECM from the MPEG-2 stream and passes the ECM 

30 to the "daughter" smartcard 48 of the end user. This slots into a housing in the receiver/decoder 13. The daughter 
smartcard 48 controls whether the end user has the right to decrypt the ECM and to access the programme. If not, a 
negative status is passed to the receiver/decoder 1 3 to indicate that the programme cannot be descrambled. If the end 
user does have the rights, the ECM is decrypted and the control word extracted. The decoder 1 3 can then descramble 
the programme using this control word. The MPEG-2 stream is decompressed and translated into a video signal for 

35 onward transmission to television set 14. 

[0139] If the programme is not scrambled, no ECM will have been transmitted with the MPEG-2 stream and the 
receiver/decoder 1 3 decompresses the data and transforms the signal into a video signal for transmission to television 
set 14. 

[0140] The Subscriber Management System (SMS) 30 includes a database 52 which manages, amongst others, all 
40 of the end user files, commercial offers (such as tariffs and promotions), subscriptions, PPV details, and data regarding 
end user consumption and authorization. The SMS may be physically remote from the SAS. 

[0141] The SMS 32 transmits messages to the SAS 30 which imply modifications to or creations of Entitlement 
Management Messages (EMMs) to be transmitted to end users. The SMS 32 also transmits messages to the SAS 30 
which imply no modifications or creations of EMMs but imply only a change in an end user's state (relating to the 
45 authorization granted to the end user when ordering products or to the amount that the end user will be charged). The 
SAS 30 also sends messages (typically requesting infomriation such as call-back information or billing information) to 
the SMS 32, so that It will be apparent that communication between the two Is two-way. 

Entitlement Management Messages (EMMs) 

50 

[0142] The EMM is a message dedicated to an individual end user (subscriber), or a group of end users, only, in 
contrast with an ECM, which is dedicated to one scrambled programme only or a set of scrambled programmes if part 
of the same commercial offer. 

[0143] Various specific types of EMM are possible. Individual EMMs are dedicated to individual subscribers, and are 
55 typically used in the provision of Pay Per View services; these contain the group identifier and the position of the 
subscriber in that group. So-called "Group" subscription EMMs are dedicated to groups of, say, 256 individual users, 
and are typically used in the administration of some subscription services. Audience EMMs are dedicated to entire 
audiences. An "audience" is the totality of subscribers having smartcards which bear the same Operator Identifier 
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(OPI). Finally, a "unique" ElVIM is addressed to tlie unique identifier of tlie snnartcard. 

[0144] Tlie general form of an EMM which is used in the preferred embodiments is now described with reference to 
Figure 3. Basically, the EMM, which is implemented as a series of digital data bits, comprises a header 60, the EMM 
proper 62, and a signature 64. The header 60 in turn comprises a type identifier 66 to identify the type of EMM , a length 
5 identifier 68 which gives the length of the EMM, an optional address 70 for the EMM, an operator identifier 72 and a 
key identifier 74. Finally, the signature 64, which is also optional, provides a number of checks against corruption of 
the remaining data in the EMM. The type identifer in the header identifies the message as an EMM. 

Subscriber Authorization System (SAS) 

10 

[01 45] Messages generated by the SMS 32 are passed via linkage 34 to the Subscriber Authorization System (SAS) 
30, which in turn generates messages acknowledging receipt of the messages generated by the SMS 32 and passes 
these acknowledgements to the SMS 32. Messages which may be passed to the SAS include subscriber suspension, 
for example, due to non-payment, subscriber modification, for example to add or remove certain commercial offers, 

15 and provide rights, for example for a specific event in PPV mode. 

[0146] The SAS 30 manages databases that store the status of all subscribers declared by the SMS 32. According 
to the status and the various messages sent by the SMS, the SAS generates EMMs for the subscribers' smartcards. 
The EMMs are ciphered by the SAS cyphering units 36 and sent to the multiplexer 4. To ensure that the EMMs are 
received by the subscriber, the SAS sends these messages cyclically The cycle depends on the type of EMM, but is 

20 typically between 30 seconds and 30 minutes. 

[0147] A typical configuration of the SAS 30 is shown in Figure 4. In overview the SAS 30 comprises a Subscription 
Chain area 1 00 to give rights for subscription mode and to renew the rights automatically each month, a Pay Per View 
(PPV) Chain area 102 to give rights for PPV events, and an EMM Injector 104 for passing EMMs created by the 
Subscription and PPV chain areas to the multiplexer and scrambler 4, and hence to feed the M PEG stream with EMMs. 

25 If other rights are to be granted, such as Pay Per File (PPF) rights in the case of downloading computer software to a 
user's Personal Computer, other similar areas are also provided. 

[0148] One function of the SAS 30 is to manage the access rights to television programmes, available as commercial 
offers in subscription mode or sold as PPV events according to different modes of commercialisation (pre-book mode, 
impulse mode). The SAS 30, according to those rights and to information received from the SMS 32, generates EMMs 
30 for the subscriber. 

[0149] The Subscription Chain area 100 comprises a Command Interface (CI) 106, a Subscriber Technical Manage- 
ment (STM) server 1 08, a Message Generator (MG) 1 1 0, and the Ciphering Unit 36. The PPV Chain area 1 02 comprises 
an Authorisation Server (AS) 112, Database Servers 114, 116 which contain relational databases for storing relevant 
details of the end users. Order Centralized Server (OCS) 118, a Server for Programme Broadcaster (SPB) 120, a 
35 Message Generator (MG) 122 whose function is basically the same as that for the Subscription Chain area, and Ci- 
phering Unit 36. 

[0150] The EMM Injector 104 comprises a plurality of Message Emitters (MEs) 124, 126, 128 and 130 and Software 
Multiplexers (SMUXs) 132 and 134. In the preferred embodiment, there are two MEs, 124 and 126 for the Message 
Generator 132, with the other two MEs 128 and 130 for the Message Generator 134. MEs 124 and 126 are connected 

40 to the SMUX 132 whilst MEs 128 and 130 are connected to the SMUX 134. 

[0151] The Message Generators 110 and 122 transform commands issued by the STM 108 and the OCS 118, re- 
spectively, into EMMs. The MGs determine the duration and the rate of emission of the EMMs. The MGs also cipher 
the EMMs using a dedicated ciphering unit. They then pass the ciphered EMM to the respective MEs, which transmit 
the EMMs cyclically. As shown in Figure 4, more than one ME can be connected to a single MG, the appropriate ME 

45 being determined by the MG according to the operator referred to in the EMM. During the lifetime of a given EMM, the 
MG stores it inside its own database. The EMM is erased from the database as soon as its emission duration has 
expired. This database ensures consistency between the MG and ME. 

[01 52] The Message Emitters 1 24, 1 26, 1 28, 1 30 receive EMMs from the respective MGs along with several param- 
eters, such as broadcast start date, broadcast stop date, and broadcast cycle. The MGs then manage the broadcast 
50 of the EMMs according to the specified parameters. 

Receiver/decoder 

[01 53] Referring to Figure 5, the various elements of receiver/decoder 1 3 will now be described in temns of functional 
55 blocks. 

[0154] The receiver/decoder 13, which may be, for example, a digital set-top box (STB), comprises a central proc- 
essor 220 including associated memory elements and adapted to receive input data from a serial interface 221, a 
parallel interface 222, a modem 223 (connected to the modem back channel 1 7 of Fig. 1), and switch contacts 224 on 
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the front panel of the decoder. 

[0155] The receiver/decoder is additionally adapted to receive inputs from an infra-red remote control 225 via a 
control unit 226 and also possesses two smartcard readers 227, 228 adapted to read bank and subscription smartcards 
242, 240 respectively. The subscription smartcard reader 228 engages with an inserted subscription card 240 and with 

5 a conditional access unit 229 to supply the necessary control word to a demultiplexer/descrambler 230 to enable the 
encrypted broadcast signal to be descrambled. The decoder also includes a conventional tuner 231 and demodulator 
232 to receive and demodulate the satellite transmission before being filtered and demultiplexed by the unit 230. 
[0156] As used in this description, an application is preferably a piece of computer code for controlling high level 
functions of preferably the receiver/decoder 13. For example, when the end user positions the focus of remote control 

10 225 on a button object seen on the screen of the television set 14 and presses a validation l<ey, the instruction sequence 
associated with the button is run. 

[0157] An interactive application proposes menus and executes commands at the request of the end user and pro- 
vides data related to the purpose of the application. Applications may be either resident applications, that is, stored in 
the ROM (or FLASH or other nonvolatile memory) of the receiver/decoder 13, or broadcast and downloaded into the 

15 RAM or FLASH memory of the receiver/decoder 13. 

[0158] Applications are stored in memory locations in the receiver/decoder 13 and represented as resource files. 
The resource files comprise graphic object description unit files, variables block unit files, instruction sequence files, 
application files and data files, as described in more detail in the above-mentioned patent specifications. 
[0159] The receiver/decoder contains memory divided into a RAM volume, a FLASH volume and a ROM volume, 

20 but this physical organization is distinct from the logical organization. The memory may further be divided into memory 
volumes associated with the various interfaces. From one point of view, the memory can be regarded as part of the 
hardware; from another point of view, the memory can be regarded as supporting or containing the whole of the system 
shown apart from the hardware. 



25 Architecture of receiver/decoder 



[0160] The receiver/decoder contains five software layers, organized so that the software can be implemented in 
any receiver/decoder and with any operating system. Referring to Figure 6, the various software layers are Application 
Layer 250, Application Programming Interface (API) layer 252, Virtual Machine Layer 254, Device Layer 256 and Sys- 

30 tem Software/Hardware Layer 258. 

[01 61 ] The Application Layer 250 encompasses applications that are either resident in or downloaded to the receiver/ 
decoder. They may be interactive applications used by customers, written in, for example, Java, HTML, MHEG-5 or 
other languages, or they may be applications used by the receiver/decoder to run such applications. This layer is based 
on a set of open Application Programming Interfaces (APIs) provided by the Virtual Machine layer. This system allows 

35 applications to be downloaded to flash or RAM memory in the receiver/decoder on-the-fly or on demand. The application 
code can be transmitted in compressed or uncompressed format using protocols such as Data Storage Media Com- 
mand and Control (DSMCC), Network File Server (NFS) or other protocols. 

[0162] Interactive applications are applications that the user interacts with, for example, to obtain products and serv- 
ices, such as electronic program guides, telebanking applications and games. The following resident applications are 
40 used to manage interactive applications: 



□ Boot. The Boot application 260 is the first application launched when the receiver/decoder is powered on. The 
Boot application starts the different "Managers" in the Virtual Machine, the first being the Application Manager 262. 

□ Application Manager. The Application Manager 262 manages the interactive applications that are run in the re- 
45 ceiver/decoder, that is, it starts, stops, suspends, resumes, handles events and deals with communication between 

applications. It allows multiple applications to run at once, and thus is involved in the allocation of resources among 
them. This application is completely transparent to the user. 

□ Setup. The purpose of the SetUp application 264 is to configure the receiver/decoder, primarily the first time it is 
used. It performs actions such as scanning for TV channels, setting the date and time, establishing user prefer- 
so ences, and so on. However, the SetUp application can be used at any time by the user to change the receiver/ 

decoder configuration. 

□ Zapping. The Zapping application 268 is used to change channels using the Program-up, Program-down and 
numeric keys. When another form of zapping is used, for example, through a banner (pilot) application, the Zapping 
application is stopped. 

55 □ Callback. The Callback application is used to extract the values of various parameters stored in the receiver/ 
decoder memory and return these values to the commercial operator via modemmed back channel 17, or by other 
means. 
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[0163] The API layer 252 provides high-level utilities for interactive application development. It includes several pack- 
ages that make up this high-level API. The packages provide all the functionality necessary to run interactive applica- 
tions. The packages are accessible by the applications. 

[0164] In a preferred embodiment the API is adapted to run applications written in the Java programming language. 

5 Furthermore, it can interpret HTML and other formats, such as MHEG-5. Besides these interpreters, it also includes 
other packages and service modules that are detachable and extensible as requirements dictate. 
[0165] The Virtual Machine layer 254 is composed of language interpreters and various modules and systems. It 
consists of everything necessary to receive and execute interactive applications in the receiver/decoder. 
[01 66] The Device Interface layer 256 includes a Device Manager and devices. Devices are software modules which 

10 consist of the logical resources necessary for management of external events and physical interfaces, The Device 
Layer manages communication channels between drivers and applications and provides enhanced error exception 
checking. Some examples of managed devices are: card readers, modems, network, PCMCIA (Personal Computer 
Memory Card International Association), LED display and so on. Programmers do not have to deal with this layer 
directly, since the API layer controls the devices from above. 

f5 [0167] The System Software/Hardware layer 258 is provided by the manufacturer of the receiver/decoder. Because 
of the modularity of the system and because services supplied by the OS (such as event scheduling and memory 
management) are part of the Virtual Machine, the higher layers are not tied to a particular real-time operating system 
(RTOS) or to a particular processor. 

20 MPEG Systems 

[01 68] Conventional digital television broadcast systems transmit data in the form of discrete transport stream pack- 
ets or transport packets, each packet being of a predetermined length and containing a header and a body. The MPEG 
standard is the currently favoured standard in this domain and sets out, amongst other things, a predetermined format 
25 for such packets. 

[0169] The packet header comprises general descriptive data regarding the packet, whilst the body comprises the 
data to be processed at the receiver/decoder. The packet header includes at least a packet ID or PID identifying the 
packet. The body of the packet may contain audio, video or other data such as application data or, in particular, con- 
ditional access system data. 

30 [0170] Conventionally, the incoming data stream is filtered by a receiver/decoder according to the PID of each packet. 
Data requiring immediate processing such as audio or visual data is communicated to an appropriate processor in the 
form of what is conventionally known as a packetised elementary stream or PES. This continuous flux of data, which 
is formed by assembling the bodies of the transport packets, itself comprises a sequence of packets, each PES packet 
comprising a packet header and body. 

35 [0171] Other data not requiring immediate processing may also be encapsulated within the bodies of the transport 
packets. Unlike PES data, which is treated immediately by a processor to generate a real time output, this sort of data 
is typically processed in an asynchronous manner by the receiver/decoder processor. In this case, data is formatted 
in a single table or a series of sections of tables, each including a header and a body, the header of the section or table 
including a table ID orTID. 

40 [0172] Various aspects of a conventional MPEG datastream will now be described with reference to Figures 7a, 7b 
and 7c which are also contained in WO 98/43431 , the disclosure of which is incorporated herein by reference. 
[0173] Referring to Figure 7a, as is known, the MPEG-2 bitstream includes a programme access table ("PAT") 310 
having a packet identification ("PID") of zero. The PAT contains references to the P IDs of the programme map tables 
("PMTs") 312 of a number of programmes. Each PMT contains a reference to the PIDs of the streams of the audio 

45 M PEG tables 314 and video MPEG tables 316 for that programme. A packet having a PID of zero, that is the programme 
access table 31 0, provides the entry point for all MPEG access. 

[0174] In order to download applications and data for them, two new stream types are defined, and the relevant PMT 
also contains reference to the PIDs of the streams of application MPEG tables 318 (or sections of them) and data 
MPEG tables 320 (or sections of them). 

50 [0175] Referring to Figure 7b, in order to download an application 322, the application is divided into modules 324 
each formed by an MPEG table, some of which are made up by a single section 318, and others of which may be made 
up by a plurality of sections 318. A typical section 318 has a header 326, which includes a one-byte table identification 
("TID") 328, the section number 330 of that section in the table, the total number 332 of sections in that table and a 
two-byte TID extension 334. Each section also includes a data part 336 and a CRC 338. For a particular module/table 

55 324, all of the sections 31 8 making up that table 324 have the same TID 328 and the same TID extension 334. For a 
particular application 322, all of the tables 324 making up that application 322 have the same TID 328, but different 
respective TID extensions. 

[0176] For each application 322, there is a single such MPEG table 324 which is used as a directory, and which is 
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shown in greater detail in Figure 7c. The directory table 340 includes a header 326, a directory part 342, a key identi- 
fication 344, an encrypted signature 346 and aCRC338. Fronn the above, it will be appreciated that the directory table 
340 has, in its header 326, the same TID 328 as the other modules/tables 324 making up the application. However, 
the directory table has a predetemiined TID extension 334 of zero, and all of the other modules 324 have non-zero 

5 TID extensions. The header also includes a version number 348 for the directory table 340, The directory part 342 
includes, for each of the other modules/tables 324 making up the application 322, the name 350 of that module, the 
TID extension 334 for that module, and a signature 352 of that module. The directory part 342 may also include, for 
each of the other modules/tables 324, the length of that module and the version number of the module. 
[0177] Referring back to Figure 7a, in operation, the PAT 310, PMTs 31 2 and application and data stream components 

10 318, 320 are cyclically transmitted, being updated as necessary, Each application which is transmitted has a respective 
predetermined TID 328. To download an application, the MPEG table having the appropriate TID and a TID extension 
of zero is downloaded to the receiver/decoder 1 3. This, therefore, is the directory table 40 for the required application. 
The data in the directory is then processed by the receiver/decoder 13 to determine the TID extensions 334 of the 
module tables making up the required application, and then any required module table having the same TID as the 

15 directory table and a TID extension determined from the directory can be downloaded. 

[0178] The receiver/decoder 1 3 is arranged to check the directory table for any updating of it. This may be done by 
downloading the directory table again periodically, for example every 30 seconds, or one or five minutes, and comparing 
the version number of the freshly downloaded directory table with the version number of the previously downloaded 
directory table. If the freshly downloaded version number is later, then the modules associated with the previous di- 

20 rectory table, or any such models for which there are later version numbers, are unmounted, and the later modules 
are downloaded and mounted. In an alternative arrangement, the incoming bitstream is filtered using a mask corre- 
sponding to the TID, TID extension and version number, with values set for the TID of the application, a TID extension 
of zero and a version number one greater than the version number of the currently downloaded directory. Accordingly, 
an increment of the version number can be detected, and once the detected directory is downloaded and the application 

25 is updated, as described above. Further description of such filtering is contained in Patent Application WO 98/43415. 
If an application is to be terminated, an empty directory with the next version number is transmitted, but without any 
modules listed in the directory. In response to receipt of such an empty directory, the receiver/decoder 13 is programmed 
to unmount the application, 

[0179] In the case where the access to a transmission is to be restricted, for example, in a pay TV system, conditional 
30 access data may be included in a table or section broadcast in the transport stream with the transmission. This con- 
ditional access data is filtered by the decoder and passed to a portable security module, such as smartcard, inserted 
in the decoder. The data is then processed by the smartcard in order to generate, for example, a control word subse- 
quently used by the decoder to descramble a transmission. 

[0180] One problem lies in the volume of data that will be received and processed by the decoder and notably the 
35 volume of conditional access data eventually forwarded to the security module. In particular, the processing capabilities 
of a security module processor and the capacity of the communication channel between the decoder and security 
module may be insufficient to handle a given volume of messages. This problem is exacerbated by the increasing 
tendency for programmes to be transmitted with multiple conditional access messages enabling access by different 
operators to the same programme (for example, a football match or a thematic television channel). Hence, a way of 
40 decreasing or at least better managing the information broadcast will be investigated presently. 

[0181] A private MPEG table section is shown below in Table 1 . This format is used uniquely to put raw data into 
MPEG sections. The maximum number of sections is dependent upon the section_syntax_indicator 
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TABLE 1 





Name 


Size 


Format 


Default 


10 
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For ( i=0;i<private_section_length- 
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} 









10 

[0182] Table 1 represents both a long table data structure, and a short table section structure, as a variant data 
structure represented by an if/else statennent. In other words, if section_syntax_indicator is equal to 0, then the table 
will have a short table data structure, otherwise the table will have a long table data structure. A short table consists 
of a single section only, whilst a long table may consist of multiple sections. 
15 [0183] In two embodiments of the invention described below, structured information replaces the raw data portions 
of both the long and short table section data structures, yielding new data formats for both. The raw data portion is 
represented in Table 1 by the loop of private_data_byte fields and will also be referred to as the section body. The 
structure of these embodiments is shown as a generic data structure in Figure 8. 

[01 84] The data structure comprises a conventional MPEG private table section header 400. The table_id_extension 
20 field 402 of the conventional header 400 is used in some embodiments to provide application-specific filtering capa- 
bilities. For example, it may be used as an identifier for the table content to enable fast retrieval of that content using 
hardware filtering. The conventional CRC information 420 is retained. 

[0185] The raw data portion (or body) of the standard MPEG private data section is replaced by further header 404 
comprising additional header fields, plus a structured data portion. The additional header fields in further header 404 

25 include information concerning compression and encryption of tables, priority, parsing format and a filter extension 
field. They also include a field specifying the size of the common attribute list 408. The common attribute list 408 
comprises attributes 406 which are common to all data items 41 2 in the data item list 41 0. The structured data portion 
further comprises a variable-length list 410 of data items 412, each including a general purpose data item identifier 
and a variable-length list 414 of attributes 41 6 specific to that data item. The length of the specific attribute lists 414 is 

30 specified in the data items 412. Attributes 416 in the item-specific attribute lists 414 may override the same common 
attributes 406 in the common attribute list 408. 

[0186] This structure enables attributes common to all data items to be included only once. Furthermore, attributes 
common to some data items may appear in the common attribute list, with those data items with values different to 
these common attributes including overriding specific attributes. This enables the space required by the formatted data 
35 to be kept to a minimum. 

[0187] Attributes will in the following also be referred to as descriptors in line with MPEG standard terminology. Lists 
will likewise also be referred to as loops as loop constructs will be used as formalisms in defining lists in specific table 
format definitions given later. 

Therefore, attribute lists 408 and 414 will also be referred to as descriptor loops, or common and specific descriptor 
40 loops respectively. Loop 410 will also be referred to as identifier loop. 

[0188] Specific examples may also give specific names to any of the data structure elements. 
[0189] A descriptor in itself may be an arbitrary data structure depending on the attribute to be represented. Prefer- 
ably, it will contain a simple header containing a descriptor tag and a descriptor size to enable automatic parsing of 
the descriptor. 

45 [01 90] By encapsulating the further header as well as the structured data within the raw data portion or body of the 
existing table structure of Table 1 , compatibility with the existing structure is maintained. This also gives compatibility 

with existing MPEG table handling hardware and software. 

[01 91 ] The private table sections will usually be generated at the broadcast centre, where information will be format- 
ted according to the structure described above. Once the data structures have been assembled in a memory at the 
50 broadcast centre, they are inserted into an M PEG stream and broadcast to receiver/decoders. A receiver/decoder may 
then retrieve the information from the MPEG stream and recreate the data structures in its memory before passing 
them to a parser for further processing as will be described below. 

[0192] A specific example of a long private table section is given by Table 2 below. Such a table may consist of up 
to 256 sections. The table gives field names, field sizes in bits, the binary data format and default values. The binary 
55 data fomiat is given using the mnemonics defined in the MPEG standard. 
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Data_conipressea_iiag 


1 

i 


DSlDI 






Data C*vnherin2 Al^nnthm 


2 


uimsbf 


See 


5 








explanation 




Data Comoressine algorithm 


2 


uimsbf 


See 


10 








explanation 




Reserved 


4 


Bslbf 


1111b 




Common_Descriptor__info_length 


12 


uimsbf 


Nl 


15 


for (i=0, i<Nl, i++) { 










Descriptor() 


















20 


for (i=0, i<N2, i++) { 










Extra_Identifier_length 


Q 
O 


uimsDi 


XT 
IN 


25 


pYtra THfTitifipr 




uimsbf 






4 


bslbf 


lUlb 




Hxtra Identifier descrintor le 


12 


uimsbf 


N3 


30 


nsth 








For ri=0 i<N3 { 

X v^x \ X X ^^x ^4^^ XI 1 / 1 










DescriDtorr'! 








35 


} 










} 










CRC_32 


32 


Rpchof 




40 


} 









Max, number of sections : 256 
Max. size for each section : 4096 



[0193] The fields between, but excluding, last_section_nunnber and CRC_32 replace the raw, unfornnatted data sec- 
tion of the existing table format of Table 1 . The new fields are now described, with the exception of reserved fields. 
50 [0194] Private_Filter_extension : In order to optimize the use of hardware filters, this 16-bit field may be used to 
extend private filtering by including further criteria in the portion of the header on which hardware filtering is performed, 

for example with MLOAD_table, MLOAD_group or MLOAD_section calls. 

[0195] Data_Parsing_Format : This 8-bit field indicates the data parsing format of the following data in the table. 
This helps automatic parsing if the format of the following data is changed in a future version. This field can be Interpreted 
55 as being equivalent to the table format version number modulo 256 in the case that more than 256 parsing formats 
are required. In that case a further header field may be introduced in a new table format for the purposes of specifying 
the parsing format. 

[01 96] Data_Cyphered_f lag : This flag indicates whether the data in the data portion or body, that is to say, the data 
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between but excluding the further header and the CRC_32 field, is enciphered or not. If the data is enciphered then 
the selection of ciphering algorithm is made with the help of the Data_Cyphering_Algorithm field. 
[0197] Data_Compressed_flag : This flag indicates whether the data in the data portion or body, that is to say, the 
data between but excluding the further header and the CRC_32 field, is compressed or not. If the data Is compressed 
then the selection of compression algorithm is made with the help of the Data_Compressing_Algorithm field, 
[0198] If both Data_Cyphered_Flag and Data_Compressed_Flag are set, then enciphering is performed after com- 
pression of the data. On the reception side, the receiver/decoder 13 deciphers before decompressing. 
[0199] Data_Cyphering_Algorithm : This 2-bit field allows for one of four different algorithms to be specified for 
use In en-/deciphering the data in the section body. 

[0200] Data_Compressing_algorithm : This 2-blt field allows for one of four different algorithms to be specified for 
compression of the data in the section body. 

[0201] Priority : One of four priority levels may be specified In this 2-blt field, which enables a priority level to be 
associated with the private data. Value 0 represents the highest priority level and value 3 represents the lowest priority 

level. 

[0202] Common_Descrlptor_info_iengtii : This specifies the length of the following common descriptor list as size 
In bytes (though the number of elements could also be used to give the length). 

[0203] Descriptor list: This Is a list of Descriptor elements. Descriptor elements may be of varied internal structure 
and represent data element attributes, The list is represented in Table 2 by a loop construction. 
[0204] Extra identifier list : This list is represented in Table 2 by a loop construction. This list may contain zero or 
more extra Identifiers, each with a descriptor list. Each element of an extra Identifier comprises the following fields: 
[0205] Extra_ldentifier_lengtli : This 8-bit field specifies the number (N) of bytes used for the variable-length 
Extrajdentlfler field. 

[0206] Extra_identifier : This 8*N-blt field specifies an Identifier or a group of Identifiers describing the following 
Extra identifier descriptor loop. 

[0207] Extra Identifier descriptor loop: This is a list of Descriptor elements. Descriptor elements may be of varied 

internal structure and represent data element attributes. This list is represented in Table 2 by a loop construction. 
[0208] In Table 1 above, the field private_section_length specifies the size of the remaining portion of the private 
section from the next field until the end of the section. The same function is performed by the Sectionjength field in 
Table 2. In Table 2, the lengths of the two descriptor loops (as size in bytes, although the number of descriptors could 
also be used) are additionally specified by the fields Common_Descrlptor_lnfo_length (default value N1) and 
Extra_ldentifier_descriptorJength (default value N3). 

[0209] An embodiment in the form of a short private table is given in Table 3 below. A short private table consists of 
only a single section. 
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TABLE 3 



Name 


Size (bits) 


Format 


Default 
value 


Short_Private_C+_section() { 








Tablejd 


8 


Uimsbf 




Section_syntax_indicator 


1 


Bslbf 


Ob 


Private_Syntax_indicator 


1 


Bslbf 


lb 


ISO reserved 


2 


Bslbf 


lib 


Section_length 


12 


Uimsbf 


Max 

value=Ox 
FFD 


Private_Filter_Extension 


56 


uimsbf 




Data_Parsing_Fonnat 


8 


uimsbf 


See 

explanati 
on 


Priority 


2 


Bslbf 


lib 


Data_Cyphered_flag 


1 


bslbf 




Data_Compressed_flag 


1 


bslbf 




Data_Cypliering_Algorithm 


2 


uimsbf 


See 

explanati 
on 


Data_Compressing_algorithm 


2 


uimsbf 


See 

explanati 
on 


Reserved 


4 


Bslbf 


1111b 


Cominon_Descriptor_info_length 


12 


uimsbf 


Nl 


for (i=0, i<Nl, i++) { 
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Descriptor() 








1 








for (i=0, i<N2, i++) { 








Extra_Identifier_length 


8 


uimsbf 


N 


Extra_Identifier 




uimsbf 




Reserved 


4 


bslbf 


1111b 


Extra_Identifier_descriptor_length 


12 


uimsbf 


N3 


for (i=0, i<N3, iH-f) { 








DescriptorQ 








} 








} 








} 









Max section number : 1 

Max size for each section : 4096 



30 [0210] The fields between, but excluding, Sectionjength and CRC_32 replace the raw, unformatted data portion - 
or body - of the existing table format. The new fields are now described, with the exception of reserved fields and the 
fields described above with reference to Table 2. 

[0211] Private_Filter_extension : In order to optimize the use of hardware filters, this 56-bit field may be used to 
extend private filtering by including further criteria in the portion of the header on which hardware filtering is performed 
35 with IVILOAD_table, l\/ILOAD_group or IVILOAD_section calls. This filter extension field is longer than the equivalent 
field in the short long format (see Table 2). This is to make the headers of both formats equal in size, which makes 
parsing of tables easier. 

[0212] Priority : One of four priority levels may be specified in this 2-bit field, which enables a priority level to be 
associated with the private data. Value 0 represents the highest priority level and value 3 represents the lowest priority 

40 level. 

[021 3] Common_Descriptor_info_length : This specifies the length of the following common descriptor list as size 
in bytes (though the number of elements could also be used to give the length). 

[0214] Descriptor list: This is a list of Descriptor elements. Descriptor elements may be of varied internal structure 
and represent data element attributes. The list is represented in Table 3 by a loop construction. 

45 [0215] Extra identifier list : This list is represented in Table 3 by a loop construction. This list may contain zero or 
more extra identifiers, each with a descriptor list. Each element of an extra identifier comprises the following fields: 
[0216] Extra_ldentifier_length : This specifies the number of bytes used for the variable-length Extra_ldentifier field. 
[0217] Extra_identifier : This specifies an identifier or a group of identifiers describing the following descriptor loop. 
[0218] Extra identifier descriptor loop: This is a list of descriptor elements. Descriptor elements may be of varied 

50 internal structure and represent data elements. This list is represented in Table 3 by a loop construction. 

[0219] The above examples of both long section and short section formats provide additional header fields related 
to compression an encryption. These provide for the ability to both encrypt and compress the formatted data portion 
and part of the additional header information. A description of compression and encryption of section bodies is given 
below. Also, a Priority field is provided to enable prioritisation of infomiation contained in private table sections. 

55 [0220] The private table formats described may be used in many different application, for example to pass instructions 
to a set top box; in a Video-on-Demand application; or in a conditional access system. Some of these examples will 
be described in more detail later. 
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The Parser 

[0221 ] To interpret the generic table structure described above, a parser is provided as part of tlie operating software 
of the set top box. The construction of such a parser given the defined data structures can easily be carried out by a 
5 person skilled in the art. Therefore, only some basic requirennents will be outlined here. 

[0222] The role of the parser is shown in Figure 9. The parser layer 506 connprising a parser provides a layer of 
abstraction between the application layer 508 and the MPEG table reception and filtering layer 504, which extracts 
infomnation sent by the broadcast system 500 via data stream 502. 

[0223] The effect of this abstraction is that the different applications do not have to be specifically adapted to a large 
10 number of different table formats for the different kinds of data they deal with. The parser processes the received table 
sections and extracts the relevant information, passing it on to an application in the application layer. 
[0224] The generic table format described above allows for different types of data to be organized within the same 
table structure. Individual data items, stored in a table section as collections of common and specific attribute descriptors 
contain the information required by an application. Descriptor formats may vary; a simple header, in the above examples 
15 comprising a tag specifying the type of information and a size attribute, is provided to enable the parser to correctly 
extract the information and pass it on to an application. 

[0225] Furthermore, the sizes of descriptor lists are provided in the form of the Common_Descriptor_info_length field 
and the Extra_ldentifier_descriptor_length field to enable the parser to accurately extract them. The parser does not 
need to concern itself with the meaning orf unction of individual data items; it simply passes the data on to an application. 

20 The parser therefore does not need to be aware of the different types of infonnation it may receive; the interpretation 
of the information is perfomned by the application. The parser merely strips the transmission-related information con- 
tained in the header and passes the actual data content of tables to the application in a suitable, generic form. 
[0226] Thus, the parser is able to process different types of tables, of variable length. The design of the parser is 
governed only by the design of the general purpose tables, not by the different types of information used by the different 

25 applications. 

[0227] To allow for further table section formats, the current format provides a parse format field 
(Data_Parsing_Format). The header section before this field remains constant in size in all table formats so that the 
parser can correctly identify the field, which it uses to determine the format of a private table section and thus choose 
the appropriate strategy for parsing it. 

30 

Compression and encryption of private tables 

[0228] The table format as described above also provides for compressed and/or encrypted private tables. Com- 
pression of private tables may be useful when the tables are used to transport large amounts of information, for example 
35 the programme catalogue in a Video-on-Demand application. Bandwidth in digital broadcast systems is often expen- 
sive, and therefore reducing the required bandwidth can be of benefit. Encryption of tables may be useful if the infor- 
mation stored in the tables is of a confidential nature, for example conditional access information. 
[0229] The compression of private tables will now be described. 

[0230] The further header as defined previously (see Table 2) includes two compression-related fields. The 
40 Data_Compressecl_flag t\ag is used to indicate whether or not the data in the private table section is compressed. 
Furthermore, the Data_Compressing_AlgorithmT\e\6 in the further header allows the algorithm used for compression 
to be specified. The system can therefore use a number of different compression algorithms at the same time. In the 
embodiment described by Table 2, this is a 2-bit field; 4 algorithms may therefore be specified. 
[0231] In a preferred embodiment described below, the standard header and footer, as well as the further header 
45 including the above-named fields, are not compressed, so that the compressed table may be processed and transmitted 
using standard MPEG hard- and software, and so that the receiver may detennine whether a table has been com- 
pressed and which algorithm was used to compress it. Only the body (or data portion) of the MPEG private table is 
compressed. In other examples, everything between (but excluding) the compression-related fields of the further head- 
er and the footer is compressed, including some fields in the further header. 
50 [0232] In some embodiments, section bodies are simply compressed individually. The table as a whole then retains 
the same number of sections after compression. 

[0233] In a preferred embodiment, however, the section bodies of all table sections are extracted from the table 
sections and assembled to form a large data block. To enable the original table sections to be recreated after decom- 
pression, each body in the block is preceded by a specifier giving its length. 
55 [0234] This intermediate data block, comprising all section bodies together with their respective lengths, is then 
compressed to give a new, compressed, data block. A new private MPEG table is then created from this block by 
splitting it into a number of segments, each of which is placed in thebody of a section of the new table. The compression 
flags in the further headers of each new table section are set accordingly. Apart from these flags and the fields relating 
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to section numbers and sizes, tlie IVIPEG standard and further lieaders otiierwise rennain the same as in the original 
table. The compressed table can therefore be handled in the same way as the original uncompressed table. 
[0235] The compressed table will usually (depending on the achieved compression ratio) contain less sections than 
the original table, as the amount of data to be transmitted has been reduced by compression. 
5 [0236] This compressed private table is then transmitted via the usual channel. When received, the 
Data_Compressed_flag indicates that the table is compressed, while the Data_Compressing_AlgohthmT\e\6 gives the 
algorithm used for compression and thus indicates to the receiver/decoder which algorithm should be used for decom- 
pression. 

[0237] The receiver/decoder then extracts the bodies from each of the compressed table sections and re-assembles 

10 it to form the original compressed data block. This is decompressed, and then, with the help of the length specifiers, 
disassembled into its constituent section bodies. These decompressed bodies are then used to recreate the original 
private table sections and hence the original private table. 

[0238] The advantage of compressing a large block of data constructed from all section bodies, rather than com- 
pressing each section body individually, is that a higher compression ratio may be achieved. Also, the number of 
^5 sections to be transmitted may be reduced. Thus, both bandwidth and computational overhead required for transmis- 
sion of the compressed private table is also reduced. 

[0239] Compression and decompression will now be described in more detail with reference to Figures 1 1 A and 1 1 B. 
[0240] Referring first to Figure 1 1 A, private M PEG Table 700 comprises N private table sections 702 through to 704. 
Each table section comprises a standard MPEG private table section header A, a further header B, a body C1 to Cn, 
20 and a footer D. In some embodiments, the table section structure is as defined previously in Table 2 or Table 3, though 
other specific structures are possible. In other examples, the further header contains other fields in addition to or instead 
of the fields given in Tables 2 and 3, or omits such fields. Also, in the long table format embodiment the footer provides 
a CRC checksum. In the short table format embodiment the footer is omitted. 

[0241] To compress table 700, section bodies C1 to Cn are extracted from table sections 1 to N. The length of each 
25 body is determined, and a data block 706 is created by assembling the bodies and preceding each body with a size 
specifier specifying the length of that body. The data block then comprises section bodies C1 to Cn, each preceded 
by their respective size specifier C1 _length to Cn_length. The inclusion of the size specifiers enables the section bodies 
to be correctly extracted after decompression. As the section length fields in both long and short table formats (as 
described above in Tables 2 and 3 respectively) are 1 2 bit fields, two byte length specifiers are sufficient in this example. 
30 The four unused bits of each two byte length specifier are set to 1 . 

[0242] Data block 706 is then compressed using any suitable compression algorithm. This results in compressed 
block 708. 

[0243] A compressed MPEG private table 710 is then produced from compressed block 708 in the following manner. 
Compressed block 708 is split into a number of segments C 1 to C'p. Each segment is then placed in a section of table 
35 71 0 as section body. Compressed table 71 0 then comprises P table sections 71 2 to 71 4 containing segments C 1 to 
C'p of compressed data block 708. 

[0244] Compressed table 71 0 may then be transmitted or stored. The compressed table is compatible not only with 
the MPEG standard private table, but also with the generic private table format as described above and can therefore 
be processed in the same way. 

40 [0245] Compressed table 710 will typically (though not necessarily) have less sections than the original uncom- 
pressed table 700 as the amount of data stored in the compressed table has been reduced through compression; and 
the compressed data has then been redistributed, preferably evenly. Therefore, transmission of the table is made more 
efficient by not only reducing the total amount of data transmitted, but also by reducing the number of table sections 
transmitted. Also, by compressing all section bodies together rather than individually, a higher compression ratio may 

45 be achieved. 

[0246] Turning now to Figure 1 1 B, compressed MPEG private table 71 0 is decompressed in the following manner. 

Section bodies C 1 to C'p are extracted and assembled to give compressed data block 71 6, which is then decompressed 
using the appropriate decompression algorithm. This results in the original uncompressed data block 71 8 comprising 
original section bodies CI to Cn with their respective size specifiers. Using the size specifiers, data block 718 is then 
50 split into its original constituents, namely section bodies C1 to Cn, and the original, uncompressed private MPEG table 
720 having table sections 722 to 724 is reconstructed from these section bodies. 

[0247] The same procedure as described above for compression of tables is used to encrypt private tables. For this 
purpose, the further header provides two fields Data_Cyphered_Flag an6 Data_Cyphering_Algorithm. These are anal- 
ogous to the compression-related fields of similar names; the first is a flag indicating whether or not a table is encrypted, 
55 whilstthesecondmay optionally be used to specify the encryption algorithm used and the decryption algorithm required 
for decryption (in other examples, this field could also be used to specify one of several encryption keys, those keys 
having been conveyed to the receiver previously). Any suitable encryption algorithm may be used, for example, DES 
or RSA. As with compression, in some embodiments encryption is performed on table sections individually, but in the 
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preferred embodiment described here, is performed on a data blocl< comprising all table section bodies with size spec- 
ifiers. This latter technique may provide increased security as the table structure is not retained. The procedure for 
encrypting a table is then analogous to the compression method described above. In fact, the technique may be used 
with any operation or transformation. Transformations in the form of compression and encryption have been described 

5 here as examples. 

[0248] Furthermore, tables may be both encrypted and compressed. In this case, data block 706 as shown in Figure 
11 A is first compressed and then encrypted. At the receiver, the compressed and encrypted table is then first decrypted 
and then decompressed (in another example, the table is first encrypted then compressed, and at the receiver, the 
encrypted, compressed table is first decompressed, then decrypted). 

10 [0249] At the receiver/decoder, decompression and decryption are performed as a first stage by the parser module. 
In an alternative embodiment, they are performed separately and before the table is passed to the parser. Since de- 
compression and decryption result in the creation of a second private table from the transmitted compressed and/or 
encrypted private table, the memory occupied by the transmitted table is released once the decompressed/decrypted 
table has been generated, as the compressed/encrypted table is then no longer needed, The receiver/decoder gen- 

15 erates a table descriptor when the table is received comprising information on the table structure and pointers to the 
table sections. The table descriptor is used to remove the compressed/encrypted table from memory. A new table 
descriptor is then created for the decompressed/decrypted table, which may, for example, be passed to another soft- 
ware module to enable the software module to access the decompressed/decrypted table. 

[0250] The decompression/decryption module detects whether a table is compressed and/or encrypted by inspecting 

20 the Data_Compressed_flag and Data_Cyphered_flag. If either of these are set, the appropriate decompression and/ 
or decryption algorithm are selected based on the value of the Data_Compressing_Algorithm and 
Data_Cyphering_AlgorithmT\e\6s. Decompression and/or decryption are then performed before further parsing occurs. 
[0251] Compression and encryption of tables is therefore transparent to the applications, and, to a large extent if not 
wholly, the parser. Since the MPEG standard header remains unchanged in the compressed and/or encrypted table 

25 and the standard MPEG private table section structure is therefore retained, compression/encryption is also transparent 
to the lower-level MPEG compliant modules concerned with transmission, reception and filtering of MPEG tables, At 
the receiver/decoder, compressed and/or encrypted tables are retrieved from the incoming stream using standard 
filtering methods, for example by filtering on the table ID and table ID extension fields. Ease of access to compressed/ 
encrypted information in MPEG streams is therefore maintained. 

30 [0252] The compression / encryption technique has here been described in the context of the generic MPEG private 
table structure discussed previously and exemplified in Tables 2 and 3. However, it is also applicable to standard MPEG 
private tables, which may be compressed and encrypted using the same technique. In some such examples, flag 
attributes such as those described are simply added at the start of the private table section bodies. In other examples 
such flags are not required if a previous agreement exists between sender and receiver on the compressed or encrypted 

35 state of the private table section bodies. The technique is also applicable to other similar data structures which are not 
MPEG private tables. 

Application Exampies 

40 [0253] The embodiments described above may be used in a number of different applications. Some examples of 
such applications will now be given. 

[0254] The first example provides a means for informing a set top box of actions to be carried out by the set top box. 
Appiication exampie: Action Notification Tabie 

45 

[0255] The action notification table (ANT) is based on the general-purpose table structure previously discussed. It 

may me used to instruct a set top box, or group of set top boxes, to carry out a particular action, 
[0256] Examples of actions to be carried out by the receiver/decoder include the downloading of software; automatic 
channel scanning; rebooting of the receiver/decoder; refreshing programme catalogues (such as a video-on-demand 
50 catalogue); and displaying a message to the user of the set top box (audience messaging). The Table ID extension 
field is used in the ANT to identify the action required. 

[0257] An ANT may be targeted at set top boxes of a particular kind (for example, from a particular manufacturer) 
or even individual set top boxes by means of targeting descriptors. These may, for example, be placed in the common 
descriptor loop of the ANT table. By processing the targeting descriptors in the common descriptor loop, a set top box 
55 may determine whether the action is to be carried out by that set top box. This processing of the targeting and action 
infomnation may, for example, be carried out by an application programme running on the set top box. 
[0258] The ANT is a table that carries lists of descriptors and loops in ordertosupportany type of action and selection 
criteria. There is no limitation for creating new descriptors. Therefore this approach is open to any new evolution. In 
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the section below, the basic structure of the ANT table is described, as well as some basic descriptors required for 
basic download purposes. 

[0259] Two table formats are available, a long table with additional header fields allowing for multi-section tables, 
and a short version allowing for a single-section table. These follow the embodiments of the invention as described 
above. The long table fonnat is shown below in Table 4a. 



TABLE 4a 



Name 


Size 
(bits) 


Format 


Default value 


Action_Notification_section() { 








Table__id 


8 


Uimsbf 


0x91 


Section_syntax_indicator 


1 


Bslbf 


lb 


Private_syntax_indicator 


1 


Bslbf 


lb 


ISO reserved 


2 


Bslbf 


lib 


Section_length 


12 


Uimsbf 


Max 

value=OxFF 
D 


Action_Identifier 


16 


Uimsbf 


See 

explanation 
below 


Reserved 


2 


Bslbf 


lib 


Version_number 


5 


uimsbf 




Current„next_indicator 


1 


Bslbf 


lb 


Section^number 


8 


uimsbf 




Last„section_number 


8 


uimsbf 




Filter_extension 


16 


uimsbf 


Following 
action_id 


Data_Parsing„Format 


8 


uimsbf 


See 

explanation 


Priority 


2 


Bslbf 


lib 


Data_Cyphered_flag 


1 


bslbf 
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Data_.Compressed_flag 


1 


bslbf 




Data_Cyphering_Algorithm 


2 


uimsbf 


See 

explanation 


Data_Compressing_algorithxn 


2 


uimsbf 


See 

explanation 


Reserved 


4 


Bslbf 


1111b 


Common_Descriptor_info_length 


12 


uimsbf 


Nl 


for (i=0, I<N1, 1++) { 








DescriptorO 








} 








for (i=0, I<N2, i++) { 








Extra_Identifier_length 


8 


uimsbf 


N 


Extra_Identifier 


8*N 


uimsbf 




Reserved 


4 


bslbf 


1111b 


ExtraJdentifier_descriptor_len 
gth 


12 


uimsbf 


N3 


for (i=0, i<N3, i+H-) { 








DescriptorO 








} 








} 








CRC_32 


32 


Rpchof 




} 









[0260] Action_identifier : The table identifier extension field (Tid_ext) is here used for a different purpose, nannely 
to identify an action. Exannples of actions and their encoding are given in Table 4b below. 



TABLE 4b 



Value 


Comment 


0x0000 


CDNT MediaOne & Jupiter 


0x0001 


Code Download V2 


0x0002 


Automatic Scanning 


0x0003.. OxFFFF 


RFU 



[0261 ] Filter_extension : The meaning of this field depends on the value of the Actionjdentifier field. Examples of 
possible values and meanings are given in Table 4c below. 
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TABLE 4c 



Actio njdentifier 


Filter_extension 


Comment 


0x0000 


>OxOOOO 


IVIessage_index 


0x0001 


OxFFFF 


Reserved for Automatic download project 


0x0002 


TBD 


RFU 


0x0003.. OxFFFF 


TBD 


RFU 



[0262] A short table format action notification table may be constructed similarly based on the short table format 
described above. 

[0263] Some examples of basic descriptors are described below with reference to Tables 4d-4k. 
Code_down load_descriptor 

[0264] One descriptor is provided for each code loader available. 

[0265] The descriptor is placed the item loop inside the ANT table, and defines the code download scheduling. 
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TABLE 4d 



Name 


Size 

(DltS) 


Format 


Default value 


Code_downioad_descriptor () { 








Descriptor_tag 


8 


Uimsbf 


Tbd 


Descriptor_length 


8 


Uimsbf 




Download_flag 


1 


Bslbf 


0 : automatic 
1 : manual 


Type 


2 


Bslbf 


0 : scheduled 
1 : immediate 
2,3 : Reserved 
for future use 


Periodicity 


2 


BslDi 


0 :no periodic 

1 : daily 

2 : weekly 

• mnntlilv 


Reserved 


3 


Bslbf 


111b 


UTC_Date_Time_start 


40 


Uimsbf 




UTC_Date_Time_estimated_st 
op 


40 


Uimsbf 




} 









Description of fields 
Down load_f lag : 
[0266] 



TABLE 4e 



Value 


Comment 


0 


The loader shall not be launched at the next reboot, but downloading parameters shall be updated in the 
EEPROM. 

To be taken into account, the download has to be activated nnanually 

• From front panel key of the STB 

• From Setup menu 
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TABLE 4e (continued) 



Value 


Comment 


1 


The code download shall actually be perfornned at the next reboot. 



[0267] Type : This field defines the STB behaviour when the download process starts 

TABLE 4f 



Value 


Comment 


0 


Immediate download 


1 


Scheduled Download 


2 


Reserved for future use 


3 


Reserved for future use 



[0268] A scheduled action enables the STB to program an automatic software download periodically (for instance 
once a day for one month at 03:00 am) until this operation is successful. 

[0269] Periodicity : This field defines the STB behaviour when the download process starts for a scheduled action, 
This periodicity is only available between the UTC_date_time_start and the UTC_date_time_estimated_stop for a 
scheduled action. 

[0270] UTC_date_tlme_start : This field indicates the scheduled date and time when a forced reboot of the STB 
shall occur. It is encoded in UTC, in the same format as specified by DVB in the TDT and TOT tables. 
[0271] UTC_date_time_estlmated_stop : This field indicates the date of availability for the code download 

ANT extension 

[0272] The ANT can be used for other types of event notification. There are no limitations; the example below de- 
scribes how to use this solution for another purpose: 

Scanning .Descriptor 

[0273] Using this descriptor, a set top box may be instructed to carry out a scan. This involves obtaining the service 
map which contains, for example, information on available channels. The scan may be required immediately, or on a 
scheduled basis. 
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TABLE 4g 



Name 


Size (bits) 


Format 


Default value 


Scanning_descriptor () { 








Descriptor_tag 


8 


uimsbf 


TBD 


Descriptor Jength 


8 


uimsbf 




Reserved 


3 


bslbf 




Service_map_version_number 


5 


uimsbf 


n 


OriginaLNetwork_id 


16 


Uimsbf 




Transport_stream_id 


16 


Uimsbf 




Scanning_flag 


1 


Bslbf 


0 : automatic 









1 : manual 


Type 


2 


Bslbf 


0 : scheduled 

1 : immediate 
2,3 : Reserved 
for future use 


Periodicity 


2 


Bslbf 


0 : no periodic 

1 : daily 

2 : weekly 

3 : monthly 


Reserved 


3 


Bslbf 


Ulb 


UTC_Date_Time_start 


40 


Uimsbf 




UTC_Date_Time_estimated_sto 
P 


40 


Uimsbf 




} 









Description of fields: 

[0274] Service_map_verslon_n umber : This field identifies the version nunnber of the service map used. 
[0275] Original_network_id, Transport_stream_id : These DVB values identify the transport streann where the 
scanning information is broadcast. 
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Scan ning_f lag : 
[0276] 



TABLE 4h 



Value 


Comment 


0 


To be taken into account, the scanning has to activated nnanually Fronn Setup nnenu 


1 


The scanning shall actually be perfornned at the next reboot. 



[0277] Type : This field defines the STB behaviour when the scanning process starts 



TABLE 4i 



Value 


Comment 


0 


Immediate scanning 


1 


Scheduled scanning 


2 


Reserved for future use 


3 


Reserved for future use 



[0278] A scheduled action makes it possible to program an automatic scanning periodically (for instance once a day 
for one month at 03:00 am), until this operation is successful. 

[0279] Periodicity ; This field defines the STB behaviour when the scanning process starts for a scheduled action. 
This periodicity is only available between the UTC_date_time_start and the UTC_date_time_estimated_stop for a 
scheduled action. 

[0280] UTC_date_time_start : This field indicates the scheduled date and time when a forced reboot of the STB 

shall occur. It is encoded in UTC, in the same format as specified by DVB in the TDT and TOT tables. 

[0281] UTC_date_time_estimated_stop : This field indicates the date of availability for the scanning service map 

information. 

[0282] The Action Notification Table (ANT) may, for example, be used to instruct the set top box to download infor- 
mation. 

[0283] Downloading data requires three mechanisms: a signalling mechanism ; a download mechanism; and a boot- 
strap mechanism. In the following description, the signalling mechanism is based on the use of a linkage descriptor 
within the NIT (Network Information Table) or the BAT to a PMT The PMT (introduced above in Figure 7a) is a table 
carrying all information necessary for the data download and identifying the location of the download stream. 
[0284] The download process may require a large variety of different types of information depending on which op- 
erator, network and set-top-box (STB) manufacturer is to be used. Therefore, a very open and flexible table concept 
is required. 

[0285] A platform is identified at a first level by an OUI Identifier. The OUI identifier indicates a particular STB man- 
ufacturer. At a second level, precise targeting is left open in order to use various parameters like Serial Number, Mac 
address, Smart-Card number linked to a CAS_ID, etc. Additional hardware or software versions and sub-versions are 
allowed. The solution described below allows any type of discrimination descriptor to be used for filtering. 
[0286] As shown in Figure 10, the signalling of a download service is based on a linkage descriptor in the NIT or the 
BAT to a PMT. In service_descriptor of SDT (Service Description Table) as well as serviceJist_descriptor of NIT, a 
service type "DOWNLOAD" is defined (in order to avoid download services appearing as programs on the screen) to 
declare this specific service. 

[0287] The PMT references an ANT (Action Notification Table) by defining a stream type "Notification" 600. An OUI 
selector is used in the PMT in order to allow a first selection of the ANT table to be used, since multiple ANT tables 
can be supported. If the receiver/decoder 1 3 finds the right OU I and the corresponding ANT, it will check in the ANT if 
the descriptors match different selection criteria and then get the entry point of the data-carousel. 
[0288] The PMT carries a selection descriptor similar to the AIT table in order to be able to view immediately if the 
ANT is carrying a download service or any other notification descriptor. 

[0289] Filtering on OUI is performed at this level. A reserved value of OUI is defined so as to select any manufacturer 
STB. 

[0290] The OUI data structure is shown below in Table 4j: 
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TABLE 4j 



Syntax 


Nbr. of Bits 


Format 


Code 


Action Notification list descriptor () 
{ 








descriptor_tag 


8 


Uimsbf 




descriptor_length 


8 


Uimsbf 




OUI 


32 


Uimsbf 


OxFFFFFF 
FF is for all 
OUI 


for(i=0; i<N; i++){ 








Action_ Identifier 


16 


uimsbf 




reserved_future_use 


3 


bslbf 




ANT version number 


5 


uimsbf 




} 









[0291] The Action_ldentifier field is equal to the action code value of the ANT i.e. the TID_Ext of the ANT 
[0292] As all tables include a version nunnber, by filtering the PMT version number change, it can be seen if an ANT 
version number has changed and which one, without having to check each ANT separately. 
[0293] The NIT or BAT linkage descriptor has the structure shown in Table 4k: 
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TABLE 4k 

5 



linkage„descriptor(){ 


length (bit) 


descriptor_tag 


8 


descriptor_length 


8 


traiisport_stream_id 


16 


original_network_id 


16 


service_id 


16 


linkage_type 


DVB defined 


for (i=0;i<N;i-h+){ 


"download 


private_data 


signalling" 


} 




} 





[0294] This linkage descriptor points to a download service where a PMT refers to one or several ANT connponents, 
[0295] In a first step, the goal is to reach a service carrying all the descriptions of available notifications. In a second 

30 step, analysis of the PMT of this service is performed. Each notification table is nnade for a specific action including 
specific selectors to affect only required STBs. So to allow for OUI filtering, the presence of an 
Action_Notification_List_descriptor under each ANT RID is mandatory. An ANT PID can carry more than one ANT 
sub_table corresponding to different action notifications from the same OUI provider. Each ANT is different from its 
TID_Extension field. If "download" is described as a possible action and the OUI code matches with the receiver, then 

35 the ANT is downloaded by the STB. Once loaded, analysis of the ANT helps to describe more precisely the matching 
download available in time. Scheduling is possible so that referencing and programming a download in the future 
without download code present in the stream at the time of programming moment is feasible. 
[0296] When matching is achieved between the download description and STB characteristics within the different 
available described code, then the STB can jump to a download code entry_point described by an association_tag, or 

40 if in another service by a deferred_association_tag, or if code is not yet available a memorization of start time and 
location has to be made by the STB. After that, it is up to the STB provider to analyse and use the data pointed to by 
the memorized entry_point (ON_ID, TS_ld, SV_ID and association_tag). The format of the downloaded data can be 
any format the provider wishes. 

[0297] Nonetheless, data shall be ordered in a way that, 

45 

• even with the first filtering, a check between STB characteristics and download code is to be made before doing 
the download => a clear identity of the code has to be defined 

• capability in the same data PID to carry multiple download codes - one per hardware version for example - means 
a way to distinguish data for each version among the whole set of present data (selection of modules in a 

50 data_carousel) 

[0298] The ANT and related mechanisms provide an extension of conventional signaling methods indicating to one 
or several set-top-boxes the location in the transport stream or in another transport stream where a new loader version 
can be found, namely a new downloadable version of their software code. 
55 [0299] The table structure described above is particularly helpful in the case of a scheduled download. 
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Application example: Targeted Tables 

[0300] As described above for the ANT table, targeting of tables is possible by including target descriptors in the 
descriptor loops. Two examples of target descriptors are given below. 
5 [0301] The first, Target_RSM_Descriptor, is used to target particular snnartcards. The second, 
Target_Platfornn_Descriptor, is used to target specific hardware and/or software platforms. 

Target_RS M_Descri pto r 

10 [0302] This descriptor, described in Table 5 below, enables an action to be carried out for a list of snnartcard identifiers, 
and is placed in the common descriptor loop of the ANT table. Several consecutive descriptors may appear in the table. 



TABLE 5 

15 



Name 


Size (bits) 


Format 


Default 
value 


Target_RSM .descriptor () { 








Descriptor_tag 


8 


uimsbf 


TBD 


Descriptor_length 


8 


uimsbf 




Ca_system_id 


16 


uimsbf 




Nuinber_of_tester 


8 


uimsbf 


N 


For (i=:0;i<N;i++) { 








RSM_serial_number 


48 


uimsbf 




QEV 


8 


uimsbf 




) 








} 









Description of fields: 

40 

[0303] Number_of_tester : This number identifies the number of RSM concerned by a download. 
[0304] RSM_serial-n umber : Qui etes Vous (available for Mediaguard smartcard) 
[0305] Qev : Qui etes Vous (available for Mediaguard smartcard) 



45 Target_Platform_Descriptor 

[0306] This descriptor, described in Table 6 below, allows an action to be carried out for a list of platform identifiers. 
It is placed in the common descriptor loop of the ANT table. Several consecutive descriptors may appear in the table, 
one per platform. 



55 
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TABLE 6 



Name 


Size (bits) 


Format 


Default 
value 


Target_Platform_aescriptor () { 








Descriptor_tag 


8 


uimsbf 


TBD 


Descriptorjength 


8 


uimsbf 




Hardware_version_number 


32 


bslbt 




Number_of„versions„concerned 


8 


uimsbf 


N 


For (i=0;i<n;i++) { 








Global_soft_id 


16 


uimsbf 




} 








} 









Description of fields: 



[0307] Hardware_version_number : This number identifies the hardware platfornn within one nnanufacturer. 
30 [0308] Number_of_versions_concerned : This nunnber identifies the number of software platforms concerned by 

a download. 

[0309] Global_soft_id : This field identifies per hardware platform the software versions of STBs concerned by the 
code download 

[0310] The Target_RSM_Descriptor (Table 5) and Target_Platform_Descriptor (Table 6) are used to target tables 
35 and table sections to particular smartcards and / or platforms. As such, they may be used in applications other than 
the Action Notification Table described above, and the Video on Demand application described below. This targeting 
functionality can be particularly useful for testing new applications, by targeting the application and related information 
at a defined set of test devices. In the Video-on-Demand application described below, targeting may also be used to 
provide, for example, different languages or different prices for different customers. By using targeting descriptors to 
40 provide multiple languages, transmission bandwidth may be saved, as only the sound component of the programme 
needs to be duplicated; the picture component remains the same regardless of the language. Targeting descriptors 
essentially provide an extension to usual table filtering methods. 

[031 1 ] Targeting descriptors may be placed both in the common and in the specific descriptor loops. Use of the first 
common descriptor loop provides a first level filter giving the common filtering parameters applicable to all possible 
45 filters. Other common information about this table may be included in this common descriptor loop. 

[0312] The identifier loop can then be interpreted as an OR condition, whilst the inner, specific descriptor loops 
provide an AND condition. For example, if three filters are declared, each having two linked conditions, the identifier 
loop will contain three items containing two descriptors each. 



50 Application exampie: Video on Demand Application 

[0313] In a second application example, both the long and short table section fomnats are used to transmit information 
to the receiver/decoder related to Video-on-Demand offerings. 

[0314] In the context of a Video-On-Demand (VoD) application, an asset catalogue is composed of metadata. This 
55 metadata comes from the Content Provider (in XML format) and is put into MPEG private sections. Those sections 
sent to the STB are broadcast in a carousel mode. 

[0315] There may be a large number of assets offered through the VoD system. A data format must therefore be 
provided that can be used for large numbers of assets, say, for example, in the tens or hundreds of thousands. 
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[0316] Considering the size of data for each asset, two levels of infornnation are provided: 

First level : providing the title, rating and category of an asset. 

5 Second level : providing the summary, actor's list, language and subtitle information, and other programme-related 

information. 

[0317] At the first level, a set of tables may be provided listing assets, for example TV programs. For easy access 
to the tables, these tables have the same Table IDs but different Table ID extensions. The Table ID extensions are 
10 used to categorize assets. For example, one table may list films, while another lists sports events. This enables the 
tables relating to a required category of assets to be extracted easily from the MPEG stream through hardware filtering. 
The user may, for example, request to see a list of sports programmes. By combining the Table ID for the asset tables 
with the category code for sports programmes in the Table ID extension field, the correct asset table may be easily 
retrieved. 

15 [0318] This table will contain a list of all assets in that category, that is to say, in this example, all sports programmes. 
This list may then be displayed to the user. If the user requests further information on one of these programmes, a 
second level table is retrieved containing further information relating to this particular asset, such as the cost of the 
programme and a description of the content, Here an asset identifier is used as the Table Identifier Extension to enable 
hardware filtering on the asset identifier and thus fast retrieval of the relevant asset information. 

20 [0319] The possible available categories are also transmitted in another MPEG private data table. The list of available 
assets constitutes a program catalogue. Further tables are provided for the update of the catalogue as will be described 
below. 

[0320] The following formats are based on the above generic format descriptions for private tables to ensure reus- 
ability of parsing modules. These formats make use of the fact that the section filtering module in the decoders is based 
25 on a hardware 8-byte mask (tablejd + 7 bytes from the tid_ext field, including the tid_ext). 

[0321] Note that the priority of categories and assets in the following tables shall be ordered with the lower value 
with the higher priority so that when information is sorted on the tid_ext field the highest priority data is retrieved first. 

Categories_Description_Table 

30 

[0322] TheCategories_Description_Table (shown below in Table 7) is the first table to be retrieved from the incoming 
stream and provides a list of available categories. The table is based on the generic long table section format previously 
described. Categoryjd is a2-bytefield identifying the category for which further infornnation is provided in the following 
descriptor list. The range of values of Gategory_id enables the use of category definitions and sub-category definitions, 
35 as described in more detail below. 

[0323] The higher byte of Gategory_id defines a category. The lower byte of Gategory_id defines a sub-category. 
Thus for example Gategoryjd 0x1200 defines category 0x12 and sub-category 0x00. Similarly, Gategoryjd 0x1234 
defines the same category 0x12 but a different sub-category 0x34. 

[0324] For example, a category_name_descriptor following Gategory_id 0x1200 may represent the visual name of 
40 the category, and the category_name_descriptor following Gategory_id 0x1 234 may represent the name of a different 
subcategory of the same category. 

[0325] Category 0x00 is a reserved value that allows a generic sub_category definition to be used. For example, if it 
is necessary to define a generic sub_category "live_event" with sub-category id 0x01 in all the possible categories 
then it is possible to define a 0x0001 value as categoryjd and a descriptor with "live_event" as text content. 

45 



50 
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TABLE 7 



Name 


Size 
(bits) 


Format 


Value / Comment 


Categories_Description 
_section() { 








Table_id 


8 


Uimsbf 


0x90 


S ec tion_syntax_indicator 


1 


Bslbf 


lb 


Private_syntax_indicator 


1 


Bslbf 


lb 


ISO reserved 


2 


Bslbf 


lib 


Sectionjength 


12 


Uimsbf 


Max value=OxFFD 


Tid_extension 


16 


Uimsbf 


Unused = 0x0000 but 
may change in future 


Reserved 


2 


Bslbf 


lib 


Version_number 


5 


uimsbf 




Current_next_indicator 


1 


Bslbf 


lb 


Section_number 


8 


uimsbf 




Last_section_number 


8 


uimsbf 




Reserved 


16 


bslbf 


OxFFFF 


Data_Parsing_Format 


8 


uimsbf 


See explanation 


Priority 


2 


Bslbf 


lib 


Data__Cyphered_flag 


1 


bslbf 




Data_Compressed_flag 


1 


bslbf 




Data_Cyphering_Algorithm 


2 


uimsbf 


See explanation 


Data_Compressing_algorithm 


2 


uimsbf 


See explanation 
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Reserved 


4 


Bslbf 


1111b 


Common_category_info__length 


12 


uimsbf 


Nl =0 


tor (1=0; i<Nl; { 








DescriptorO 








I 








ror (1=0; i<N2; i++) { 








Catcgory„Id_length 


8 


uimsbf 


N = 2 


Category_id 


8*N 


uimsbf 




Reserved 


4 


bslbf 


1111b 


Category_descriptor_length 


12 


uimsbf 


N3 


for 0=O,j<N3,j++) { 








DescriptorO 








I 








} 








CRC_32 


32 


Rpchof 




} 









[0326] The descriptors to be stored in tlie category_descriptor_loop are shown below in Table 8. 
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Category_name_descriptor 
[0327] 

5 

TABLE 8 



Name 


Size (bits) 


Format 


Value / Comment 


Category_name_descriptor() { 








descriptor_tag 


8 


Uimsbf 


0xC9 


descriptor_length 


8 


Uimsbf 




Category_code 


8 


Uimsbf 




ISO_639_Language„Code 


24 


Uimsbf 




Category_name_length 


8 


Uimsbf 





25 



for (i=0; i<N; i++) { 








Category_name_char 


8 


Uimsbf 




} 








} 









35 

ASSET tables 

[0328] The first level of asset information is based on tlie long format syntax for private sections 
40 (Section_syntax_indjcator = 1). 

[0329] Each table corresponds to a specific category and sub_category identified by their respective identifiers. A 

table can describe more than 1 0000 assets since it can be made of 256 sections of 4 kbytes each. 

[0330] The category and sub_category ratings (which replace the tid_ext field) lie in the hardware filter depth to 

ensure fast filtering of a group of assets based on rating criteria. Ratings are encoded in 8 bits to be consistent with 
45 the DVB parental_rating_descriptor that is used in the MediaOne PPV application. 

[0331] Each table is made of an asset_id loop. A first descriptor loop carries common attributes which apply to all 

asset_id. 

[0332] A second descriptor loop carries specific attributes which apply to a particular asset. When an atthbute is 
defined in the first and second loop, the second definition overrides the common definition. 
50 [0333] The structure of the asset information table section is shown in Table 9. 



55 
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TABLE 9 





Size i^Diisj 


Format 


vaiiie / i_-oiiiinciii 


AcQf*t infnrmfitinn "sprtionO i 








Table iH 


o 


T TlTTIQVif 
LJlllloLrl 


0x91 


.^i=^f*tinn QviitJiTC inHiratnr 


1 
1 


JLJolL/i 


1h 


1 IIVCLXX/ aVlltClA. il.ivt-lW'CltWl 


1 
1 


T?<ilM 

UolL^l 


lb 

X LI 


T^^^ f*=^cf "^^7■^*H 


9 


XJollJl 


1 lb 

± 1 LI 


LjCrV/ LlVJll ^l^ll^Lll 


19 

1 ^ 


T Ti mclrf 

LJllllAUl 


IVJ^OA. VillLlty— V-/A.1 X XJ 


V^ClLCg,vJl Jr ^lU. 


Q 
o 


T TitticItF 

UllllOUl 


Tid ext 


O LIU V^a.Lt'g,^! y ^ILL 


o 


7 TinridTF 

VJlllloLfl 


rvCJ^CI VCLi 


9 




1 lb 
1 i u 


V CI oHJlJ IJ Ul llLJCl 


u 


n 1 mcV*i 
U. 1 ! 1 lo IJ I 






1 

1 


Bslbf 


1 u 


OC/V^ llUll llUlllL/til 


Q 
o 


111 m<;bf 




J_/u.o I oCU LI XJL 1 ^1 1 Uiil L/Cl 


Q 
o 


n 1 mebf 
umio L/i 




r^5if"i=^OT*r\/ rati nor 


o 


iiiin^bf 

L11111l> LJl 




uu L/O-LCKUiy j[xa.tiii& 


» 


LilllloLfl 




L/ciLci rciiaiiig. 1 VJiiitaL 




ni rricbf 

LllllloLrl 


vJb^ \^J\^\J\.<XL\.Ck\,i\J%.\ 




9 


Bslbf 


lib 


LJCLla^ .V^y UllClCLl lltt^ 


1 
1 








1 


bslbf 




Ojitfl l^vnhf*rino Alcroritlinn 
j--'Cit<i_\_' y L/iit'i iiiK ■f^ig.t-Ji 1 null 


2 


nim^bf 

Ul IX JCI \.j3L 




J-VCIKI X^'K^lllJLIl t'Oi>lll^__Cllgl_ll -lU.il 11 


2 


ui msbf 


See exulanation 




4 


Bslbf 


1111b 


r^nmmnti A^^f*>t info Iptiafh 

V^t^llllllV^JLl .f^JO\.yL l.im_> l^ll^Lll 


12 


iiimsbf 


Nl 


for (i=0; i<Nl;i++) { 








DescriptorO 








} 








For (i=0; i<N2; i++) { 








Asset_Id_length 


8 


uimsbf 


N 


Asset_id 


8*N 


uimsbf 
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Reserved 


4 


bslbi 


1 1 1 1 !_ 

1111b 


Asset_descriptor_length 


12 


uimsbf 


TV TO 

N3 


for(j=0,j<N3,j++) { 








DescriptorO 








} 








} 








CRC_32 


32 


Rpchof 




} 









Asset_id_length : number of bytes used to define the value field 

Asset_id : Identifier or group of identifiers describing the following descriptor loop. 

[0334] The second level of asset infomnation is based on the short format syntax for private sections 
(Section_syntax_indicator = 0). 

[0335] Due to the hardware filter depth, it is possible to set up a filterto access a specific asset_id. The 24-bit reserved 
field is defined to be consistent with the generic format for short section syntax. It actually complements the hardware 
filter mask. 

[0336] A descriptor loop is used to encode attributes which are related to an asset. 
[0337] The table section structure is described in Table 1 0. 



TABLE 10 



Name 


Size (bits) 


Format 


Value / 
Comment 


Asset_inore_informatioii_section() { 








Tablejd 


8 


Uimsbf 


0x92 


Section_syntax_indicator 


1 


Bslbf 


Ob 


Private_Syntax_indicator 


1 


Bslbf 


lb 


ISO reserved 


2 


Bslbf 


lib 
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o ecuon_iei ui 


1 7 




TV/Toy 

value=OxFFD 






T Tim^Hf 




I? <=»CptT'\/f='rl 


24 


T Tim*jlif 

\J AJL1J.O J- 


OxFFFFFF 




o 




exnlanation 




2 


Bslbf 


lib 




1 

J. 


bslbf 






1 

X 


b«;lbf 






9 


nim^b'f 


See exnlanation 




2 


nim^bf 


See exnlanation 


JVCoCI vcva 


4 


Bslbf 


1111b 




12 


iiim^ibf 

IXllXloLvX 


Nl 


for (i=0; i<Nl; i++) { 








DescriptorQ 








} 








} 









[0338] Some possible descriptors for inclusion in the descriptor loops of either the Asset_infornnation_section or the 
Asset_nnore_information_section are now described. 

Asset_name_descriptor 

[0339] This descriptor is placed in the asset loop of the Asset Information Table. Its structure is described in Table 1 1 . 



TABLE 11 



Name 


Size (bits) 


Format 


Value / Comment 


Asset_name„descriptor() { 








Descriptor_tag 


8 


Uimsbf 


OxCl 


Descriptor Jength 


8 


uimsbf 




Start_date 


40 


Bslbf 
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40 

TV/ 


Bslbf 






8 


T TitncKf 




ISO f»?0 lanmiape Code 


24 


T Tim^lrf 


vSf*p nnrm 


Titlf' Ipnath 

i ILlt' 1^11^ 111 


t> 


T Tim<shf 


Max Ox3C 


For (i=0; i<N; i++) { 








Title^char 


8 


Uimsbf 




} 








} 









[0340] The following descriptors are normally placed in the Asset_more_infoimation_table. However, some of these 
may also be used as attributes in the Asset_lnformation_Table. 

source_descriptor 

[0341] This descriptor, defined in Table 12 below, provides information about aspects of the presentation format of 
an asset. 

TABLE 12 



Name 


Size (bits) 


Format 


Value / Comment 


Source_descriptor() { 








Descriptor_tag 


8 


Uimsbf 


0xC2 


Descriptorjength 


8 


Uimsbf 




Reserved 


6 


Bslbf 


111111b 


Surround 


1 


Bslbf 




Widescreen 


1 


Bslbf 




Language 


24 


Bslbf 




Subtitle_language 


24 


Bslbf 




} 









Asset_mo re_i nf o_desc r i pto r 

[0342] This descriptor, defined in Table 13 below, provides miscellaneous infomnation about an asset. 
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TABLE 13 



Name 


Size (bits) 


Format 


Value / Comment 


Asset_more_info_descriptor() { 








Descriptor„tag 


8 


Uimsbr 




Descriptor_length 


o 

8 


uimsbf 




Duration 


24 


bslbi 




Retail_price 


48 


bslbi 




Year 


32 


1 ii_ J? 

bslbi 




Provider_Coiintry__Code 




uimsDr 




Provider_nameJength 


8 


Uimsbf 


Max 0x10 


for (i=0; i<N; i++) { 








Provider_name_char 


8 


uimsbf 




} 








} 









Asset_description_descriptor 

[0343] This descriptor, defined in Table 14 below, provides a textual description of an asset. 



TABLE 14 



Name 


Size (bits) 


Format 


Value / Comment 


Asset_description_descriptor() { 








Descriptor_tag 


8 


uimsbf 


OxC5 


Descriptor_length 


8 


uimsbf 




ISO_639_Language_Code 


24 


uimsbf 




For(j=0;j<N;j++) { 
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Description_char 


8 


uimsbf 




} 








} 









Acto rs_desc ri pto r 

[0344] This descriptor, defined in Table 15 below, provides infornnation about an actor appearing in an asset such 
as a film. 



TABLE 15 



Name 


Size (bits) 


Format 


Value / Comment 


Actors_descriptor() { 








Descriptor_tag 


8 


Uimsbf 


OxC6 


Descriptor_length 


8 


Uimsbf 




ISO_639Janguage_Code 


24 


Uimsbf 




for a=0;j<N;j++){ 








Actors_char 


8 


uimsbf 




} 








} 









Package_descriptor 

[0345] This descriptor, defined in Table 16 below, provides infornnation relating to a package of assets. 
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TABLE 16 





Size rbits) 


Format 


Value / Comment 


Package descriDtorr^ f 










8 


Uimsbf 


0xC7 


Descriptor_length 


8 


Uimsbf 




ISO_639_language_Code 


24 


uimsbf 




for (i=0; i<N; i++) { 








Package_char 


8 


Uimsbf 




} 








} 









[0346] The following descriptors apply to all assets, so they should be located in the common descriptor loop of the 
Asset Information Table or if it is necessary to override a specific asset then it can be repeated in the assetjoop. 

Checkout_Length_descriptor 

[0347] This descriptor, defined in Table 1 7 below, provides infomnation about the checkout length. It provides a mech- 
anism for timing out connections to the VoD server. 

TABLE 17 



Name 


Size (bits) 


Format 


Value / Comment 


Checkoutlength_descriptor() { 








Descriptor_tag 


8 


Uimsbf 


0xC4 


Descriptorjength 


8 


uimsbf 




CheckoutLength 


16 


uimsbf 




} 









Stream_controLdescriptor 

[0348] This descriptor, defined in Table 1 8 below, provide stream control information. It is defined as a variant data 
structure formalised using if -statements. 
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TABLE 18 



Name 


Size (bits) 


Format 


Value / Comment 


Stream_control _descriptor() { 








Descriptor_tag 


8 


uimsbf 


OxC8 


Descriptor_length 


8 


uimsbf 




Control_flags 


8 


uismbf 


See explanation 


If (Pause^Control == 1 ) { 








PauseLimitSeconds 


16 


uimsbf 




ActionOnPauseLimits 


8 


uimsbf 




1 








If (Fast_Forward„Control == T) 
{ 








PauseLimitSeconds 


16 


uimsbf 




ActionOnPauseLimits 


8 


uimsbf 




1 








If (Rewind_Control = T) { 








PauseLimitSeconds 


16 


uimsbf 




ActionOnPauselimits 


8 


uimsbf 




} 








} 









[0349] The Control_flags attribute is described in Table 19 below. 



TABLE 19 



Bit 


Description 


Comment 


0 


Pause control 


0 : disabled / 1 : enabled 


1 


Fast Forward control 


0 : disabled / 1 : enabled 


2 


Rewind control 


0 : disabled / 1 : enabled 


3. .7 


Reserved 





Catalogue update 

[0350] When the VoD application is launched, the Asset Infornnation Tables are loaded to display available assets. 

(Category ratings are taken into account in order to hide categories with unauthorised movies). 

[0351] When the subscriber needs additional information for a specific asset, it loads the corresponding 
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Asset_nnore_information_table. 

[0352] Furthermore, to update asset information, the following Catalog_Update_table, as described in Table 20, may 
be broadcast, which indicates the category and sub-category that should be updated. 



TABLE 20 



Name 


Size (bits) 


Format 


Value / 
Comment 


Catalog_update_section() { 








Tablejd 


8 


Uimsbf 


0x93 


Section_syntax_indicator 


1 


Bslbf 


lb 


Private_section_indicator 


1 


Bslbf 


lb 


ISO reserved 


2 


Bslbf 


lib 


Section_length 


12 


Uimsbf 


Max 

value=OxFFD 
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Reserved 


1 £i 


Uimsbf 




Reserved 


Z 


rJslDI 


1 1 K 
1 ID 


Version_number 


c 
3 


uimsbf 




Current_next_indicator 


1 


oSlDI 


iD 


S ection_number 


0 


uimsbf 




Last_section_number 


0 
0 


uimsbf 




Update_counter 


0 
0 


uimsbf 




Reserved 


A 

4 


JdSIDI 


111 IK 
1 i I ID 


Current_Action_flags 


4 


DSlDI 




Data_Parsing_Format 


0 
8 


uimsbf 


See explanation 


Priority 


2 


rJslDi 


i Id 


Data_Cyphered_flag 


1 


DSlDI 




Data_Compressed„flag 


1 


DSlDI 




Data„Cyphering_Algorithm 


z 


uimsbf 


See explanation 


Data_Coinpressing__algorithm 


2 


uimsbf 


See explanation 


Reserved 


4 


DSlDI 




Counter_descriptor_loopJength 


12 


uimsbf 




For (i=0; i<N; 1++) { 








^aiegory__oescripiors^^^ 








} 








CRC32 


32 


Rpchof 




} 









[0353] update_counter : This counter is incremented by one each tinne the catalogue has been fully updated. When 
only Sonne modifications occur, this counter is incremented by one. The first value of Update_Counter field is 0. When 
the database extractor is reset, this counter may be reset to value 0 but the Current_Action_Flags field shall be set to 
0001 to indicate a full update of the complete database. A modulo 256 has to be taken into account when occuring at 
the STB level. The update counter enables the STB to determine when new information needs to be downloaded. 
[0354] Category_counter_descriptor : The counter descriptor identifies a version counter for an asset information 
table. It enables a STB to determine when asset information has been updated so that it may download up-to-date 
infonnation. 

[0355] Current_action_flags : Various flags may be simultaneously raised corresponding to available 
category_descriptors in the inner loop. The individual flags are listed in Table 21 . 
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TABLE 21 



Bit 


Comment 


0 


Full_update_action 


1 


Partial_Add_update_action 


2 


Partial_Change_update_action 


3 


Partial_Remove_Update_Action 



[0356] Some descriptors are now described which may appear in the descriptor loops of the Catalog_update_section. 
Category_Counter_descriptor 

[0357] This descriptor, defined below in Table 22, provides a category/subcategory update counter. 

TABLE 22 



Name 


Size (bits) 


Format 


Value / Comment 


Category„counter_descriptor() { 








Descriptor_tag 


8 


Uimsbf 


OxCB 


Descriptor_length 


8 


Uimsbf 




Categoryjd 


8 


Uimsbf 




Sub_category_id 


8 


Uimsbf 





Counter 


8 


uimsbf 




} 









[0358] counter : This 8-bit field counts the update of the Asset_lnfonnation_Table and related 
Asset_more_information_tablefor a particular category and sub-category. 

Category_Act io n_desc ri pto r 

[0359] This descriptor, defined below in Table 23, provides information relating to the kind of update required for the 
specified category and subcategory combinations. 
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TABLE 23 



Name 


Size (bits) 


Format 


Value / Comment 


Category_Action_descriptor() { 








Descriptor„tag 


8 


Uimsbf 


OxCC 


Descriptor_length 


8 


Uimsbf 




Action 


o 

8 


uimsbi 




For (i=0;i<n:i++) { 








Categoryjd 


8 


Uimsbf 




Sub„category_id 


8 


Uimsbf 




} 








} 









[0360] Action : This 8 bits field specifies the action to be performed during catalogue update on the list of categories 
and sub-categories contained in the loop. Possible actions are given in Table 24. 

TABLE 24 



Value 


Action 


0x00 


Update All (no loop of Tidext after) 


0x01 


Add some categories 


0x02 


Change some categories 


0x03 


Remove some categories 



Plantjd mechanism 

[0361] The plantjd mechanism is used to establish a VOD session connection with a selected server. First the 
receiver/decoder 13 retrieves an initialization file defined below in Table 25 and scans all frequencies available in the 
lookup_frequency_list_descriptor loop shown in Table 27 until it is possible to tune into one of the scanned frequencies . 
When one frequency is found then it is necessary to filter on the PID described in this same descriptor a Plant_ld 
definition table with tidext equal to PlantJd_selection field (always in the same descriptor) to retrieve the right 
Service_Group_ld. In parallel, the application connects to an http server using the routingjp descriptor available in 
the common_descriptor_loop of the VOD_initialization_table to retrieve the IP address of the VOD server. 
[0362] The Syntax of the VOD_initialization_section is shown in Table 25 below. 
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TABLE 25 







J; UFiniti 


v«tiuc/ v^umiiiciii 










Tablejd 


8 


Uimsbf 


0x94 


Section_syntax_indicator 


1 


Bslbf 


Ob 


Private_Syntax_indicator 


1 


Bslbf 


lb 


ISO reserved 


2 


Bslbf 


lib 


Sectionjength 


12 


Uimsbf 


Max value=OxFFD 
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Pnvate_Filtering_Extension 


56 


uimsbf 




Data_Parsing_Format 


8 


uimsbf 


See explanation 


Priority 


2 


Bslbf 


lib 


Data_Cyphered_flag 


1 


bslbf 




Data_Compressed_flag 


1 


bslbf 




Data_Cyphering_Algorithm 


2 


uimsbf 


See explanation 


Data„Compressing_algorithm 


2 


uimsbf 


See explanation 


Reserved 


4 


Bslbf 


1111b 


Common_Descriptor_info_lengt 
h 


12 


uimsbf 




for (i=0, i<Nl,i++) { 








DescriptorO 








} 








For (i=0, i<N2, i++) { 








Plant Jdjength 


8 


uimsbf 


N 


Plant_Id 


8*n 


uimsbf 




Reserved 


4 


bslbf 


Ullb 


Plant_id_descriptorJength 


12 


uimsbf 


N3 


for (i=0, i<N3, i++) { 








DescriptorO 








} 








} 








} 









[0363] Private_Filtering_Extension : In order to optimize use of hardware filters, this 56_bit field may be used to 

extend private filtering with MLOAD_table, MLOAD_group or MLOAD_section calls. 

[0364] Plant_id_length : number of bytes used to define the Extra_identifier field 

[0365] Plant_id : One identifier or a group of identifiers described by the following descriptor loop. 

[0366] Descriptors used in the VODJnitialisation_section of Table 25 are described below. 

Cable_delivery_system_descriptor 

[0367] The Cable_delivery_descriptor, defined In Table 26 below, may be located in the common_descriptor_loop 
with a frequency_field set to 0000.0000 Mhz. It will help to give default modulation parameters for all following frequen- 
cies. 
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TABLE 26 



Syntax 


Bit Size 


Format 


Value/ Comment 


Cable_deli very_system_descriptor() { 








Descriptor_tag 


8 


Uimsbf 


0x44 


Descriptorjength 


8 


Uimsbf 




Frequency 


32 


bslbf 




Reserved_future_use 


12 


bslbf 




FEC_outer 


4 


bslbf 




Modulation 


8 


Bslbf 




Symbol__rate 


28 


Bslbf 




FEC„inner 


4 


Bslbf 




} 









[0368] Possible descriptors in the plant_id_descriptor_loop are as follows: 

Lookup_Frequency_List_descriptor 

[0369] This descriptor is defined in Table 27. 



TABLE 27 



Name 


Size 
(bits) 


Format 


Value / 

Comment 


LookUp__Frequency_List_Descriptor () { 








Descriptor_tag 


8 


uimsbf 


OxCD 
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ucscripior^iengcn 


Q 
O 


uimsbf 




— n • 1 • T 1 1 \ r 
For (^1— u,i<n,i++j [ 








Frequency 


JZ 


DSibr 




rvCSCr Vcu 




DSIDI 


1 1 1K 
i i ID 




1 J 


n im cl^f 
UllliaUi 




Plaat_id_Selection 


16 


uimsbf 


Optional 


} 








} 









[0370] Frequency : This is a 32 bit field giving tine 4-bit BCD values specifying 8 characters of the frequency value. 

The frequency is coded in MHz where the decinnal occurs after the fourth character 

[0371] Plant_ld_PID : The PID value where the receiver/decoder 1 3 can find the plant_ID files. 

[0372] Plant_id_Selection : This 1 6 bit field nnay be the Tid_ext value to be filtered on the PID while the TID value 

is static to retrieve the correct Plant_ld_Definition_Table. This field is optional for future extension only. If optional its 

value shall be set to OxFFFF. 

[0373] Note : In a further example the reserved and Plant_ld_P ID fields nnay be nnerged in order to give an association 
tag value that will help to find the real PID value while it is always difficult to exploit a systenn with static data PID 

referencing. 

[0374] The three following descriptors should be set in the connnnon descriptor loop as Http ODA sen/er 

Connection_data_descriptor 

[0375] This descriptor is defined in Table 28. 
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TABLE 28 



k3 J 11 let A 




l?Al*lTI5lf 


Value/ 
Cornment 


Cnnnpftinn Hata rlp^sfntitor (\ 1 








T^pcprir>tnr tap 


g 


T Timsbf 


OxE8 


Descri ntor 1 en 2th 


8 


Uirnsbf 




T OQ^in namp Ipnp'th 

ijVJil|J.ii lidl.LIv-' IV-^IJc^LLl 


8 


I Jimshf 




For ri=0 • i^N • i+^-'i i 








T OCTin nanriF' 

J-^l^ &1 11 11 CU 11W> 


8*n 














Password_length 


8 


Uimsbf 




For (i=0 ; i<N ; i++) { 








Password 


8*n 


uirnsbf 




} 








} 









Routing_lpv4_descriptor 

[0376] This descriptor is defined in Table 29. 



TABLE 29 



Syntax 


Bit Size 


Format 


Value/ 
Comment 


routing_descriptor_ipv4 () { 








descriptor_tag 


8 


uimsbf 


0x06 


descriptor_length 


8 


uimsbf 




for(i=0; i<N; i++) { 








component^tag 


8 


uimsbf 




Address 


32 


uimsbf 
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port_number 


16 


uimsbf 




address mask 


32 


uimsbf 




} 








} 









[0377] The Connponent_tag field is not used in this exannple. Its value is set to 0. 

Routing_ipv6_descriptor 

[0378] This descriptor is defined in Table 30. 

TABLE 30 



Syntax 


Bit Size 


Format 


Value/ 
Comment 


Routing_descriptor_ipv6 () { 








Descriptor_tag 


8 


uimsbf 


0x07 


Descriptor lenqth 


8 


uimsbf 




For(i=0; i<N; i++) { 








Component_tag 


8 


uimsbf 




Address 


128 


uimsbf 




port_number 


16 


uimsbf 




address_mask 


128 


uimsbf 




} 








} 









[0379] The Component_tag field is not used in this exanriple. Its value is set to 0. 
[0380] Table 31 defines the syntax of the Plant_ID_Definition_Section. 
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TABLE 31 





(bits) 




Value / 
Comment 


Plant_Id_Dcfinition_section() { 








1 aUlC iU 


o 


T Tim^Hf 


0x95 




1 
1 




lb 


i^riVaic_oyuiaA_iiiuic<iiur 


1 

J. 


Rslbf 


lb 


Ljkj rescrvcu- 


7 


Bslhf 


lib 


o ecuon_icngLii 


19 


T Ti m^Hf 


XVJLclA. 

value=OxFFD 


r 1 all L__1U. OClCw LlULi 




T li rrmh"f 


Tid cxt 




2 


Bslbf 


lib 


Version_number 


5 


uimsbf 




\^urreni_ncAi_iriuicdior 


1 




lb 


o eciion_nurnDer 


« 

o 







i^aSi_scciion nuniDer 


o 






jr 1 1 Lcr_ex icn s loii 


1 u 






Data_Parsing_Foriiiat 


8 


uimsbf 


See 

exnlanation 


Priority 


2 


Bslbf 


lib 


Data_Cyphered_flag 


1 
1 






Data_Conipressed„flag 


1 
1 






iJai^_i^ypnering_AJgoriinrn 


z> 


111 tn cV^'F 


exnlanation 




2 


uimsbf 


See 

explanation 


Reserved 


4 


Bslbf 


llUb 


Common_Descriptor_infoJeiigth 


12 


uimsbf 


Nl 


for (i=0; i<Nl;i+4.) { 








DescriptorO 








} 
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CRC_32 


32 


Rpchof 




1 









VOD_Service_Group_Descriptor 

[0381] This descriptor, described in Table 32 below, is used within the Plant_ld_definition_section. 



TABLE 32 



Name 


Size (bits) 


Format 


Value / 
Comment 


VOD__Service_CTroup__Descriptor () { 








Descriptor_tag 


8 


uimsbf 


OxCE 


Descriptor_length 


8 


uimsbf 




Service_groupJdentifier 


32 


uimsbf 




} 









30 Use of VOD Signalization 

[0382] The section below discusses how to use standard and private C+ signalization to retrieve the dedicated VOD 
tables from the stream. 

[0383] It is first necessary to declare a VOD Portal Service. This is done with help of a service type equal to private 
35 value OxDO indicating that this service is a VOD one. This service type is to be reported in the service_list_descriptor 
of the ON IT and in the service_descriptor of the SNT (Service Network Table). 

[0384] This service should find the necessary declaration to activate the VOD application; VOD service type decla- 
ration may be enough to achieve this. 

[0385] Then, in the component loop of the PMT belonging to this service, there will be found a loop of private data 
40 elementary streams with stream_type OxG1 and an attached PID. Each stream of this stream_type shall contain an 
appli_list_descriptor to define which of these data are broadcast into this PID. 
[0386] The syntax of the appli_list_descriptor is given in Table 33 below. 
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TABLE 33 



Syntax 


Bit Size 


Format 


Value/ 
Comment 


Appli_list_descriptor() { 








Descriptor_tag 


8 


uimsbf 


0xC2 


Descriptor_length 


8 


uimsbf 




for (i=:0;i<N;i++){ 








appli_name 


64 


uimsbf 


8 char 


} 








} 









[0387] We should then find as applLname (restricted to 8 chars) 

25 □ VODJNIT as for the VOD_lnitialization_Table 

□ ASSET as for Asset_lnformation_Table (name shall be filled with space up to 8 chars) 

□ DETAILS as for Asset_More_lnformation_Table. 

□ CATEGORY as for Categories_Definition_Table 

□ UPDATE as for the Catalog_Update_Table (nanne shall be filled with space up to 8 chars). 

30 

[0388] Note that for broadcast, ASSET and CATEGORY may be put into the same PID so that two 
appli_list_descriptors shall be present under this PID so that split in the future will be easier 

[0389] DETAILS, due to the amount of data and cycling period, should be in a different PID to ASSET and CATE- 
GORY 

35 [0390] The VOD application, when starting, first displays the categories and, if the user requires, shows details 
present in ASSET tables. Once the PID of the data is defined, it is allowed to use direct allocated TID value to do 
filtering instead of complete DMT mechanism to speed up the access to information. (DMT shall be broadcast anyway 
giving the resolution between TID and table_name - same as in appli_list_descriptor). 

[0391 ] During parsing of the catalogue, the U PDATE table shall be monitored in case a change occurs in categories 
40 or assets. 

[0392] Then, once the user has made his choice, the VOD application uses the VOD_INIT data to scan its hub 
frequency. See Plant_ld_mechanism above for more details. 

[0393] Once a correct frequency is retrieved, and tuning is possible, at least one Plant_ld_Definition_Table is to be 
broadcast on a PID defined in the first PMT of the transport stream. By first PMT is meant that this is the first service 
45 declared within the PAT that should contain one elementary stream of stream_type OxC1 with appli_list_descriptor 
containing PLANT_ID name in it. This PID is the PID value also described in the lookup_frequency_list_descriptor of 
the VOD_initialization_table for this frequency. This mechanism is established in order to be DVB compliant and so as 
not have a ghost PID. 

[0394] Then, on this PID, a plant_ld_definition_Table is broadcast with TIDExt value equal to the Plant_ld_Selection 
50 value already defined in the lookup_frequency_list_descriptor of the VOD_initialization_table for the current tuned 
frequency. If this filtering does not match then a try for another frequency is made. Furthermore, a time-out (value tbd) 
to retrieve the Plant_ld_Definition_Tablefor agiven frequency shall imply a jump to the next described frequency within 
the current lookup_frequency_list_descriptor of the VOD_initialization_table. 

[0395] If a complete loop is made without any match then an explicit error is displayed or a new try is made for the 
55 complete frequency list available. 

[0396] Explicit error means one of the following possibilities: 

• No frequency found 
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• No Plant_id table found for a tuned frequency 

• No PAT signalization on the frequency found 

• No PMT signalization on the frequency found 

5 [0397] Otherwise, with the help of IP_descriptors of VOD_initialization_Table, the address of a server is found in 
order to establish a VOD session connection. 

[0398] The foregoing description has defined a private table structure based on the following approach: 

• a nnodel for a short section; 

10 • a model for a long section; and 

• an application context descriptor list. 

[0399] This system described above provides the following strategic advantages: 

^5 • nnore efficient development; 

• the creation of an application implementation independent of the manufacturer of the receiver/decoder 1 3 and the 
manufacturer of the conditional access system. 

• An increase in the amount of disposable data without increasing the cost - this is done via data compression; and 

• Easier development of product updates 

20 

[0400] The system also provides the following advantages for the application broadcast: 

• the creation of a table parser; 

• evolution of the parser does not have a large impact on existing applications; 
25 • normalisation of the definition of a private table; 

• the developer can only act on the data filtering and the descriptor for his needs; 

• Easier processing of table contents; 

• the extraction of data is ensured by the parser; 

• ensures an ascending compatibility with data formats; 

30 • integration with existing formats - private sections can use existing DVB descriptors whilst DVB tables can use 
private descriptors; 

• guarantee of non-regression; 

• association of an Object method with a descriptor; 

• facilitation of unitary tests and integration; 

35 • facilitation of operational integration (on site, without perturbing live broadcast); and 

• a reduction in the time needed to develop an application. 

[0401] It will be understood that the present invention has been described above purely by way of example, and 

modifications of detail can be made within the scope of the invention. 
40 [0402] Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided 
independently or in any appropriate combination. 



Claims 



45 



1. A data structure for an MPEG private table section including a data portion, the data structure comprising a size 

specifier specifying a measure of the size of the section or the data portion, the data portion comprising at least 
one data block, the or each block including a further size specifier specifying a measure of the size of that block. 

50 2. A structure according to claim 1 , wherein the data portion comprises a plurality of data blocks, each including a 
respective one of such further size specifiers. 

3. A data structure for an MPEG private table section including a data portion, the data portion comprising a plurality 
of data blocks, each block including a size specifier specifying a measure of the size of its respective block. 



55 



4. A structure according to claim 1 , 2 or 3, further comprising a list of blocks. 

5. A structure according to claim 4, wherein such list includes a list specifier specifying a measure of the overall size 
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of the blocks in the list. 

6. A structure according to ciainn 4 or 5, comprising a plurality of such lists. 

7. A structure according to claim 6, further comprising at least one block having data common to such plurality of lists. 

8. A structure according to any of claims 4 to 7, wherein the or each block in such list has data specific to its particular 
list. 

9. A structure according to claim any of claims 4 to 8, comprising a plurality of blocks in such list. 

10. A structure according to any of claims 4 to 9, further comprising an identifier representative of the content of a 
respective list. 

11. A structure according to any of the preceding claims, wherein the size specifier is located in a header portion of 
the block. 

12. A structure according to any of the preceding claims, wherein at least one such block includes a tag representative 
of its content. 

13. A data structure for an MPEG private table, comprising only one structure as claimed in any of claims 1 to 12. 

14. A data structure for an MPEG private table, comprising a plurality of structures as claimed in any of claims 1 to 1 2. 

15. A data structure for an MPEG private table section, comprising an MPEG standard header, a further header and 
a data portion. 

16. A structure according to claim 15, wherein the further header includes a flag representative of the state or type of 
transformation of the data. 

17. A structure according to claim 15 or 1 6, wherein the further header includes a filter specifier 

18. A structure according to any of claims 15 to 17, wherein the further header comprises a field for specifying a parser 
type. 

19. A structure according to claim 1 8, wherein the parser type field is the first field of the further header 

20. A structure according to any of claims 15 to 19, wherein the further header comprises a field for specifying the 
priority with which the private table section is to be processed. 

21. A data structure comprising a plurality of compressed data blocks, wherein the compressed data blocks can be 
decompressed to provide a plurality of decompressed data blocks, each decompressed data block including a 
data portion and a size specifier specifying the size of the data portion. 

22. A structure according to claim 21 wherein the number of decompressed data blocks is greater than the number of 
compressed data blocks. 

23. A structure according to claim 21 or 22 further comprising a header associated with each compressed data block. 

24. A data structure comprising a plurality of encrypted data blocks, wherein the encrypted data blocks can be de- 
crypted to provide a plurality of decrypted data blocks, each decrypted data block including a data portion and a 
size specifier specifying the size of the data portion. 

25. A structure according to claim 24 further comprising a header associated with each decrypted data block. 

26. A structure according to claim 24 or 25 wherein the header is a standard MPEG header 

27. A compressed MPEG private table section. 
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28. A compressed MPEG private table, comprising at least one compressed MPEG private table section as claimed 
in claim 27. 

29. A compressed MPEG private table. 

30. An encrypted MPEG private table section. 

31. An encrypted MPEG private table, comprising at least one encrypted MPEG private table section as claimed in 
claim 30. 

32. An encrypted MPEG private table. 

33. An MPEG private table section comprising target information wlnich identifies a receiver/decoder or group of re- 
ceiver/decoders wliich is an intended recipient of the MPEG private table section. 

34. An MPEG private table, comprising at least one MPEG private table section as claimed in claim 33. 

35. An MPEG private table comprising target information whicli identifies a receiver/decoder or group of receiver/ 
decoders which is an intended recipient of the MPEG private table. 

36. An MPEG private table or private table section according to any of claims 33 to 35, wherein the target information 
identifies a software or hardware platform. 

37. A method of processing data comprising converting such data between a given format and data in the format of 
a data structure as claimed in any of claims 1 to 36. 

38. A method of assembling an MPEG private table, comprising providing a data portion and adding a flag represent- 
ative of a state or type of transformation of the data portion. 

39. A method according to claim 38 wherein the data portion is a transformed data portion which has been subject to 
a transformation. 

40. A method of performing a transfomnation on an MPEG private table, thetable comprising a data portion, the method 
comprising compressing, decompressing, encrypting or decrypting the data portion so as to form a transformed 
data portion. 

41 . The method of claim 40 further comprising adding a flag representative of the state of transformation of the trans- 
formed data portion. 

42. The method of claim 40 or 41 further comprising adding a flag representative of the type of transformation performed 
on the data portion. 

43. A method of performing a transformation on a plurality of data blocks, comprising assembling the data blocks to 
form an intermediate block and perfomriing a transformation on the intermediate block, so as to form a transformed 
block. 

44. A method according to claim 43, wherein the transfomriation comprises splitting a block into a plurality of sub-blocks. 

45. A method according to claim 44, further comprising adding a flag representative of the state of transformation of 
the data to a sub-block. 

46. A method according to claim 44 or 45, further comprising adding a flag representative of the type of transformation 
to a sub-block. 

47. A method according to any of claims 43 to 46, further comprising transmitting the transformed block to a recipient. 

48. A method according to claim 47, further comprising receiving the transformed block. 
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49. A method according to any of claims 44 to 48, further comprising performing a further transformation on the trans- 
formed block. 

50. A method according to claim 49, wherein said further transformation is the inverse of said transformation. 

51. A method according to claim 49 or 50 when dependent on claim 44, wherein performing a further transformation 
comprises assembling the sub-blocks so as to form a further intermediate block, and performing the further trans- 
formation on the further intermediate block. 

52. A method according to any of claims 44 to 51 further comprising adding a standard header to each sub-block. 

53. A method according to any of claims 43 to 52, wherein the assembling step comprises including in the intemnediate 
block size specifiers each specifying the size of a respective data block. 

54. A method according to any of claims 43 to 53, further comprising inspecting a size specifier in a block to determine 
how the block should be split into sub-blocks. 

55. A method according to any of claims 43 to 54, wherein the transformation is a compression, decompression, 
encryption or decryption. 

56. A method according to any of claims 43 to 55 wherein said plurality of data blocks are data portions of an MPEG 
private table. 

57. A method according to any of claims 43 to 56, further comprising forming a transformed M PEG private table having 
at least one transformed data portion provided by the transfonned block. 

58. A method according to claim 56 and 57 wherein the MPEG private table comprises a plurality of table sections 
each including a standard header and a data portion, and the transformed M PEG private table comprises a plurality 
of table sections each including a standard header and a transformed data portion provided by the transformed 
block. 

59. The method of claim 57 or 58 wherein at least a part of a header in the transformed MPEG private table is sub- 
stantially identical to a part of a header in the MPEG private table. 

60. A method according to claim 57,58 or 59, further comprising including a value in the transformed MPEG private 
table specifying the type of transformation. 

61. A method according to any of claims 57 to 60, further comprising including a value in the transformed MPEG private 
table specifying the state of transformation of the transformed data portion. 

62. A method of transmitting an MPEG private table, comprising performing a transformation on the MPEG private 
table using a method according to any of claims 56 to 61 , and transmitting the transformed table. 

63. A method of receiving an MPEG private table, comprising receiving the MPEG private table and performing a 
transformation on the received table using a method according to any of claims 56 to 61 . 

64. A method according to any of claims 36 to 63 wherein the data portions or blocks contain action notification data 
for reception by a receiver/decoder and for controlling a function of the receiver/decoder. 

65. A method according to any of claims 36 to 64 wherein the data portions or blocks contain programme information 
for use in a video-on-demand system. 

66. A method according to any of claims 36 to 65 wherein the data portions or blocks contain key data for use by a 
receiver/decoder to obtain access to a conditional access system. 

67. A method according to any of claims 36 to 66 further comprising adding target information which identifies a re- 
ceiver/decoder or group of receiver/decoders which is an intended recipient. 



62 



EP 1 267 579 A2 



68. A method of assembling an MPEG private table section, the method comprising inserting target information which 
identifies a receiver/decoder or group of receiver/decoders which is an intended recipient of the MPEG private 
table section. 

69. Apparatus for assembling an MPEG private table, comprising means (for instance in the form of a processor with 
associated memory) for providing a transformed data portion which has been subject to a transformation and 
means (for instance in the form of a processor with associated memory) for adding a flag representative of the 
type of transformation. 

70. Apparatus for performing a transformation on an MPEG private table, the table comprising a data portion, the 
apparatus comprising means (for instance in the form of a processor with associated memory) for compressing, 
decompressing, encrypting and/or decrypting the data portion so as to form a transformed data portion. 

71 . Apparatus for performing a transformation on a plurality of data blocks, comprising means (for instance in the form 
of a processor with associated memory) for assembling the data blocks to form an intermediate block and means 
(for instance in the form of a processor with associated memory) for performing a transformation on the intermediate 
block, so as to form a transformed block. 

72. Apparatus for assembling an MPEG private table section, the apparatus comprising means (for instance in the 
form of a processor with associated memory) for inserting target information which identifies a receiver/decoder 
or group of receiver/decoders which is an intended recipient of the MPEG private table section. 

73. A parser comprising means (for example in the form of a processor with associated memory) for parsing an MPEG 
private table or table section according to any of claims 27 to 36, or for parsing data having a data structure 
according to any of claims 1 to 26, or for parsing data which has been processed, assembled or transformed by 
a method according to any of claims 36 to 68. 

74. A parserfor parsing an MPEG private table section comprising an MPEG standard header and a data portion, the 
MPEG standard header including a TID extension field, comprising means (for example in the form of a processor 
with associated memory) for outputting the value of the TID extension field. 

75. A parser adapted to perform a method as claimed in any of claim 36 to 68. 

76. A receiver/decoder including a parser according to claim 73,74 or 75. 

77. A receiver/decoder according to claim 76 as dependent on claim 74, including means (for example in the form of 
a processor with associated memory) for receiving the value of the TID extension field and for processing such 
value. 

78. A receiver/decoder according to claim 77 wherein said receiving and processing means is adapted to process 
such value as a notification to a user of the receiver/decoder 

79. A receiver/decoder according to claim 77 wherein said receiving and processing means Is adapted to process 
such value as data concerning content received by the receiver/decoder 

80. A receiver/decoder adapted to receive and/or decode data In a data structure as claimed In any of claims 1 to 26. 

81. A receiver/decoder adapted to receive and/or decode an MPEG private table or table section according to any of 
claims 27 to 36, or which has been processed, assembled ortransfonned by a method according to any of claims 
37 to 68. 

82. A receiver/decoder adapted to receive and/or decode data which has been processed, assembled or transformed 
by a method according to any of claims 37 to 68. 

83. A transmitter adapted to transmit data In a data structure as claimed In any of claims 1 to 26. 

84. A transmitter adapted to transmit an MPEG private table or table section according to any of claims 27 to 36, or 
which has been processed, assembled or transformed by a method according to any of claims 37 to 68. 
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85. A transmitter adapted to transmit data which has been assembled or transformed by a method according to any 
of claims 37 to 68. 

86. A broadcasting system incorporating a receiver/decoder according to any of claims 76 to 82 and a transmitter 
5 according to any of claims 83 to 85. 

87. A broadcasting system according to claim 86, wherein the data is conditional access data, the system being adapt- 
ed to transmit and receive such data on a separate channel. 

10 88. A computer readable medium embodying a parser or apparatus as claimed in any of claims 69 to 75. 

89. A signal tangibly embodying a parser or apparatus as claimed in any of claims 69 to 75. 

15 
20 
25 
30 
35 
40 
45 
50 
55 



64 



EP 1 267 579 A2 



FIG. 1 
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Fig. 7a 
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